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ABSTRACT 


In  the  development  of  large  distributed  systems,  both  the  detection  and  resolution 
of  inconsistency  in  policy,  requirements,  and  specifications  pose  major  challenges.  The 
purpose  of  this  thesis  is  to  examine  the  inconsistencies  in  policy,  requirements,  and 
specifications  in  the  development  of  information/Joint  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  systems.  In  this  thesis,  we  explore 
the  application  of  a  “viewpoints”  framework  to  aid  in  the  development  of  distributed 
information  systems. 

A  viewpoints  framework  methodology  that  was  developed  to  aid  in  the 
development  of  distributed  systems  is  the  Reference  Model  of  Open  Distributed 
Processing  (RM-ODP).  This  thesis  is  concerned  with  the  application  of  the  five 
viewpoints  of  RM-ODP  and  the  translation  of  policy  into  requirements  and  specifications. 
In  this  thesis  we  use  the  Ballistic  Missile  Defense  (BMD)  system  as  a  case  study  to 
explain  how  RM-ODP  can  be  used  to  develop  distributed  information  systems.  We 
found  that  identifying  inconsistencies  regarding  interoperability  amongst  the  subsystems 
of  BMD  necessitated  the  use  of  multiple  viewpoints  and  that  firm  conclusions  could  not 
be  made  until  the  system  was  viewed  at  the  lower  levels. 
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EXECUTIVE  SUMMARY 


In  the  development  of  large  distributed  information  systems,  both  the  detection 
and  resolution  of  inconsistency  in  policy,  requirements,  and  specifications  pose  major 
challenges.  The  purpose  of  this  thesis  is  to  examine  inconsistencies  in  policy, 
requirements,  and  specifications  in  the  development  of  distributed  information/Joint 
Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems.  In  this 
thesis,  we  explore  the  application  of  a  “viewpoints”  framework  to  aid  in  the  development 
of  distributed  information  systems. 

A  viewpoints  framework  methodology  that  was  developed  to  aid  in  the 
development  of  distributed  systems  is  the  Reference  Model  of  Open  Distributed 
Processing  (RM-ODP).  This  thesis  is  concerned  with  the  application  of  the  five 
viewpoints  of  RM-ODP  and  the  translation  of  policy  into  requirements  and  specifications. 
A  case  study  of  the  Ballistic  Missile  Defense  (BMD)  system  is  presented  in  order  to 
illustrate  how  RM-ODP  can  be  used  in  the  definition  of  requirements  and  specifications 
and  in  the  detection  of  inconsistencies  in  policy,  requirements,  and  specifications.  The 
BMD  system  is  a  good  candidate  to  model  using  viewpoints  because  it  is  a  complex, 
distributed,  heterogeneous  system  comprised  of  many  subsystems. 

Ballistic  missile  defense  involves  many  challenges.  One  of  these  challenges  is  the 
ability  to  hit  a  moving  target.  Another  major  challenge  facing  BMD  is  that  of 
interoperability  amongst  all  the  systems.  The  RM-ODP  viewpoints  can  be  used  to  aid  in 
modeling  the  BMD  system  to  help  address  some  of  these  challenges.  Through  the  use  of 


IX 


RM-ODP,  the  various  members  of  the  development  team  can  communicate  their  policy, 
requiements,  and  specifications  for  the  composite  system  using  a  common  set  of 
languages  and  mappings  between  the  languages  (i.e,  levels  in  the  five-layer  viewpoint 
model). 

In  the  case  study  the  interoperability  problem  facing  the  BMD  system  is  addressed 
using  the  RM-ODP  viewpoints  framework.  The  case  study  demonstrates  how  the 
viewpoints  can  be  applied  at  a  very  abstract  level. 

Much  research  has  been  done  in  the  area  of  viewpoints.  The  concepts  of 
viewpoints  and  inconsistency  management  in  software  development  are  introduced. 
Much  of  the  previous  research  stresses  the  importance  of  conflicts  in  software 
development  and  suggests  that  conflicts  are  a  necessary  part  of  the  development  process 
and  should  be  represented  and  understood.  The  use  of  a  policy  workbench  to  aid  in 
analyzing  proposed  policy,  maintaining  a  policy  database,  and  assisting  in  policy 
enforcement  is  also  discussed.  Lastly,  policy  conflicts  and  the  problems  of  conflict 
detection  and  resolution  in  distributed  systems  are  presented. 

We  found  that  identifying  inconsistencies  regarding  interoperability  amongst  the 
subsystems  of  BMD  necessitated  the  use  of  multiple  viewpoints  and  that  firm  conclusions 
could  not  be  made  until  the  system  was  viewed  at  the  lower  levels.  These  findings  can  be 
used  by  U.S.  DoD  as  a  tool  to  aid  in  the  development  of  distributed  information  systems. 
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I. 


INTRODUCTION 


A.  PROBLEM  STATEMENT 

Many  questions  remain  to  be  answered  regarding  how  to  best  develop  large 
distributed  systems.  Among  other  things,  both  the  detection  and  resolution  of 
inconsistencies  in  policy,  requirements,  and  specifications  pose  major  challenges. 

A  distributed  system  is  a  set  of  computers,  connected  by  at  least  one  network,  that 
do  not  share  memory  or  a  common  clock.  The  goal  of  a  distributed  system  is  to  cause  a 
set  of  computers  to  appear  to  the  user  as  a  single,  powerful  virtual  machine.  There  are 
five  primary  advantages  offered  by  distributed  systems:  resource  sharing  (hardware  and 
software  can  be  shared  among  computers);  enhanced  performance  (higher  throughput  and 
speed  through  increased  concurrency);  improved  reliability  (through  replication  of  data 
files  and  services,  distributed  systems  can  be  made  more  fault  tolerant);  improved 
availability  (some  components  may  fail  without  affecting  the  overall  availability  of  the 
system);  and  modular  expandability  (hardware  and  software  can  be  added  without 
adversely  impacting  existing  resources). 

The  purpose  of  this  thesis  is  to  examine  the  inconsistencies  in  policy  (rules  or  a 
means  of  specifying  and  influencing  behavior  within  a  distributed  system),  requirements, 
and  specifications  in  the  development  of  distributed  information/Joint  Command, 
Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems.  In  this  thesis,  we 
explore  the  application  of  a  “viewpoints”  framework  to  aid  in  the  development  of 
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distributed  information  systems.  A  viewpoints  framework  is  used  to  partition  a  system 
specification  into  a  number  of  different  components.  Each  component  (viewpoint)  is  a 
complete  and  self-contained  description  of  the  required  distributed  system  targeted 
towards  a  particular  audience  (development  team  participant). 

B.  MOTIVATION 

One  viewpoints  framework  methodology  that  was  developed  to  aid  in  the 
development  of  distributed  systems  is  the  Reference  Model  of  Open  Distributed 
Processing  (RM-ODP).  RM-ODP  allows  developers  to  view  the  system  as  an  interrelated 
whole  rather  than  as  a  collection  of  parts,  and  provides  a  way  in  which  distributed 
systems  and  their  features  can  be  described.  Much  work  has  been  done  with  the  RM- 
ODP  approach  to  systems  development.  This  thesis  is  concerned  with  the  application  of 
the  five  viewpoints  of  RM-ODP  and  the  translation  of  policy  into  requirements  and 
specifications.  This  thesis  will  use  the  Ballistic  Missile  Defense  system  (which  is  a  large 
distributed  system)  as  a  case  study  to  explain  how  RM-ODP  can  be  used  in  the  definition 
of  requirements  and  specifications  and  in  the  detection  of  inconsistencies  in  policy, 
requirements,  and  specifications. 

C.  SCOPE 

The  scope  of  this  thesis  is  limited  to  application  of  the  five  viewpoints  of  RM- 
ODP  to  managing  inconsistency  when  developing  distributed  information  systems,  in 
particular  the  Ballistic  Missile  Defense  system.  This  research  will  provide  conclusions 
and  recommendations  for  dealing  with  inconsistencies  in  the  definition  of  policy. 
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requirements,  and  specifications  for  information  systems/Joint  C4I  systems.  The 
resulting  conclusions  and  recommendations  in  this  research  are  intended  to  aid  the  U.S. 
Department  of  Defense  (DoD)  in  the  development  of  systems  so  that  inconsistencies  are 
caught  as  early  in  the  life  cycle  as  possible. 

D.  ORGANIZATION 

The  organization  of  this  thesis  is  as  follows:  Chapter  II  provides  an  overview  of 
RM-ODP  and  discusses  the  five  viewpoints  in  detail.  Chapter  IH  describes  some  of  the 
previous  research  most  closely  related  to  this  thesis.  The  concepts  of  viewpoints  and 
inconsistency  management  in  software  development  are  introduced.  Much  of  the 
previous  research  stresses  the  importance  of  conflicts  in  software  development  and 
suggests  that  conflicts  are  a  necessary  part  of  the  development  process  and  should  be 
represented  and  understood.  The  use  of  a  policy  workbench  to  aid  in  analyzing  proposed 
policy,  maintain  a  policy  database,  and  assist  in  policy  enforcement  is  also  discussed. 
Lastly,  policy  conflicts  and  the  problems  of  conflict  detection  and  resolution  in 
distributed  systems  are  presented.  Chapter  IV  provides  an  overview  of  the  BMD 
system.  Chapter  V  uses  the  BMD  system  as  case  study  to  demonstrate  how  RM-ODP  can 
be  used  to  aid  in  the  definition  of  requirements  and  specifications.  Chapter  VI  provides 
the  resulting  conclusions  and  recommendations  in  this  research.  Suggestions  for  future 
research  are  also  discussed. 
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II.  RM-ODP 


A.  INTRODUCTION 

Advances  in  computer  networking  have  allowed  computer  systems  across  the 
world  to  be  interconnected.  Despite  this,  heterogeneity  of  computer  systems  is  still  a 
problem.  Open  Distributed  Processing  (ODP)  describes  systems  that  support 
heterogeneous  distributed  processing  both  within  and  between  organizations  through  the 
use  of  a  common  interactive  model.  The  International  Standards  Organization  (ISO)  and 
the  International  Telecommunication  Union  -  Telecommunications  Standardization 
Sector  (ITU-T)  have  developed  the  Reference  Model  of  Open  Distributed  Processing 
(RM-ODP)  to  provide  a  coordinating  framework  for  the  standardization  of  ODP  by 
creating  an  architecture,  which  supports  distributing,  internetworking,  interoperability, 
and  portability.  RM-ODP  is  a  standardized  framework  for  modeling  such  systems. 
[HERR97]  The  goal  of  RM-ODP  is  to  achieve  the  following: 

•  Portability  of  application  across  heterogeneous  systems 

•  Interlocking  between  ODP  systems;  that  is,  meaningful  exchange  of  information 
and  the  convenient  use  of  functionality  throughout  the  distributed  system 

•  Distribution  transparency;  that  is,  hide  the  consequences  of  distribution  from  both 
the  applications  programmer  and  user  [ENTE99] 

The  following  distribution  transparencies  defined  in  RM-ODP  [IS0395]: 
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•  Access  transparency  -  hides  the  differences  in  data  representation  and  procedure 
calling  mechanism  to  enable  interworking  between  heterogeneous  computer 
systems 

•  Failure  transparency  -  masks  the  failure  and  possible  recovery  of  objects,  to 
enhance  fault  tolerance 

•  Location  transparency  -  masks  the  use  of  physical  addresses,  including  the 
distinction  between  local  and  remote 

•  Migration  transparency  -  masks  the  relocation  of  an  object  and  its  interfaces  from 
other  objects  and  interfaces  bound  to  it 

•  Relocation  transparency  -  hides  the  relocation  of  an  object  and  its  interfaces  from 
other  objects  and  interfaces  bound  to  it 

•  Replication  transparency  -  maintains  consistency  of  a  group  of  replicated  objects 
with  a  common  interface  and  is  used  to  enhance  performance  and  availability 

•  Persistence  transparency  -  masks  the  deactivation  and  reactivation  of  an  object 

•  Transaction  transparency  -  hides  the  coordination  required  to  satisfy  the 
transactional  properties  of  operations 

The  reference  model  provides  the  “big  picture”  that  organizes  the  pieces  of  an 
ODP  system  into  a  coherent  whole.  It  does  not  try  to  standardize  the  components  of  the 
system  or  unnecessarily  influence  the  choice  of  technology. 

The  RM-ODP  architecture  uses  the  notion  of  viewpoints  as  an  abstraction 
mechanism.  The  viewpoints  on  an  ODP  system  and  its  environment  are  as  follows: 
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•  Enterprise  viewpoint  (purpose,  scope,  and  policies) 

•  Information  viewpoint  (semantics  of  information  and  information  processing) 

•  Computational  viewpoint  (functional  decomposition) 

•  Engineering  viewpoint  (infrastructure  required  to  support  distribution) 

•  Technology  viewpoint  (choices  of  technology  for  implementation)  [FEUS99] 
Specifying  an  ODP  system  using  the  viewpoint  languages  allows  for  an  otherwise 

large  and  complex  specification  of  an  ODP  system  to  be  separated  into  manageable 
pieces,  each  focused  on  the  issues  relevant  to  a  member  of  the  development  team.  For 
example,  the  systems  analyst  works  with  the  information  specification  while  the  systems 
programmer  is  concerned  with  the  engineering  viewpoint.  Figure  1  shows  how  the  RM- 
ODP  viewpoints  can  be  related  to  the  software  engineering  process  of  requirements 
analysis,  functional  specification,  design,  and  implementation. 


Figure  1.  RM-ODP  Viewpoints  and  Software  Engineering 
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The  five  viewpoints  are  discussed  in  the  following  sections. 


B.  ENTERPRISE  VIEWPOINT 

The  enterprise  viewpoint  focuses  on  the  purpose,  scope,  and  policies  for  the 
system.  In  the  enterprise  viewpoint,  social  and  organizational  policies  can  be  defined  in 
terms  of  objects,  communities,  and  roles  of  the  objects  within  the  communities. 

1.  Objects 

Objects  are  classified  as  either  “active”  or  “passive.”  Some  examples  of  active 
objects  are  bank  managers,  tellers,  and  customers.  Examples  of  passive  objects  are  bank 
accounts  and  money.  [IS0395] 

2.  Communities 

Communities  are  groupings  of  objects  intended  to  achieve  some  purpose.  An 
example  of  a  community  is  a  bank  branch.  The  bank  branch  consists  of  objects  (bank 
manager,  tellers,  and  bank  accounts),  which  provide  banking  services  to  a  geographical 
area  (purpose).  [IS0395] 

3.  Roles  of  Objects 

Roles  of  the  objects  within  the  communities  are  expressed  in  terms  of  policies. 
Policies  dictate  the  behavior  of  objects  within  a  community.  Policies  have  varying  scope. 
They  may  apply  across  a  community,  to  a  role,  or  to  a  single  action  type.  Policies  can  be 
either  implicit  or  explicit.  Implicit  policies  are  derived  from  the  specification  of  a  role, 
enteiprise  object,  or  action.  An  explicit  policy  is  one  for  which  policy  is  specified  in  its 
own  right.  [IS0395] 
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Policies  consist  of  three  components:  1)  Permissions,  2)  Prohibitions,  and  3) 
Obligations.  Permissions  describe  what  can  be  done;  for  example,  money  can  be 
deposited  in  an  open  bank  account.  Prohibitions  describe  what  must  not  be  done;  for 
example,  customers  must  not  withdraw  more  money  than  they  have  in  their  bank  account. 
Obligations  describe  what  must  be  done;  for  example,  the  bank  manager  must  advise 
customers  when  the  interest  rate  changes.  Permissions  and  prohibitions  are  defined  by 
actions,  roles  involved  in  that  action,  predicates  on  behavior,  and  an  authority,  which 
either  grants  the  permission  or  imposes  the  prohibition.  [MICH99] 

4.  Enterprise  Language 

The  enterprise  language  is  a  structured  set  of  concepts,  rules,  and  structures  for  the 
specification  of  an  ODP  system  using  the  enterprise  viewpoint.  It  is  specifically 
concerned  with  performance  actions  that  change  policy,  such  as  creating  an  obligation  or 
revoking  permission.  In  a  bank,  the  changing  of  interest  rates  is  a  performance  action 
since  it  creates  obligations  on  the  bank  manager  to  inform  customers  of  the  change. 
However,  obtaining  an  account  balance  is  not  a  performance  action  because  obligations, 
permissions,  and  prohibitions  are  not  affected.  [ISO  195] 

By  imposing  an  enterprise  specification  of  an  ODP  application,  policies  are 
determined  by  the  organization  rather  than  imposed  on  the  organization  by  technology 
(implementation)  choices.  For  example,  a  customer  should  not  be  limited  to  having  only 
one  bank  account  because  it  is  more  convenient  for  the  programmer  to  implement. 


9 


C.  INFORMATION  VIEWPOINT 


The  information  viewpoint  focuses  on  the  semantics  of  information  and 
information  processing.  The  information  viewpoint  is  used  to  describe  the  information 
required  by  an  ODP  application  through  the  use  of  schemas,  which  describe  the  state  and 
structure  of  an  object.  An  example  of  an  information  viewpoint  is  the  information  about 
a  bank  account  object,  which  consists  of  a  schema  containing  the  balance  and  the 
“amount  withdrawn  today.”  [IS0395] 

A  static  schema  captures  the  state  and  structure  of  an  object  at  some  particular 
instance;  for  example,  at  midnight,  the  amount  withdrawn  today  is  $0.  An  invariant 
schema  restricts  the  state  and  structure  of  an  object  at  all  times;  for  example,  the  amount 
withdrawn  today  is  less  than  or  equal  to  $500.  A  dynamic  schema  defines  a  permitted 
change  in  the  state  and  structure  of  an  object;  for  example,  a  withdrawal  of  $n  from  an 
account  decreases  the  balance  by  $n  and  increases  the  amount  withdrawn  today  by  $n. 
Dynamic  schemas  are  constrained  by  any  existing  and  applicable  invariant  schemas. 
[IS0395] 

Schemas  can  also  be  used  to  describe  relationships  or  associations  between 
objects;  for  example,  the  static  schema  “owns  account”  could  associate  each  account  with 
a  customer.  A  schema  can  be  composed  from  other  schemas  to  describe  complex  or 
composite  objects;  for  example,  a  bank  branch  consists  of  a  set  of  customers,  a  set  of 
accounts,  and  the  “owns  account”  relationships.  The  information  specification  of  an  ODP 
application  can  be  expressed  using  a  variety  of  methods;  for  example,  entity-relationship 
models  and  conceptual  schemas.  [IS0395] 
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D.  COMPUTATIONAL  VIEWPOINT 


The  computational  viewpoint  focuses  on  the  functional  decomposition  of  the 
system  into  objects,  which  interact  at  interfaces.  The  computational  viewpoint  is  used  to 
specify  the  functionality  of  an  ODP  application  in  a  distribution-transparent  manner. 
RM-ODP’s  computational  viewpoint  is  object-based.  The  objects  encapsulate  data  and 
methods,  offer  interfaces  for  interaction  with  other  objects,  and  offer  multiple  interfaces. 
[IS 0395] 

The  computational  viewpoint  further  defines  the  objects  within  an  ODP  system, 
the  activities  within  those  objects,  and  the  interactions  that  occur  among  objects.  Most 
objects  in  a  computational  viewpoint  describe  application  functionality,  and  these  objects 
are  linked  by  bindings  (e.g.  a  communication  path)  through  which  interfaces  occur. 
Binding  objects  are  used  to  describe  complex  interactions  between  objects.  [IS0195] 
Figure  2  illustrates  a  bank  branch  object  providing  a  bank  teller  interface  and  a  bank 
manager  interface.  Both  interfaces  can  be  used  to  deposit  and  withdraw  money,  but 
accounts  can  be  created  only  through  the  bank  manager  interface.  Each  of  the  bank 
branch  object’s  interfaces  is  bound  to  a  customer  object. 
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Figure  2.  Bank  Branch  Object  with  Bank  Manager  and  Bank  Teller  Interfaces 


E.  ENGINEERING  VIEWPOINT 

The  engineering  viewpoint  focuses  on  the  infrastructure  required  to  support 
distributed  interaction  between  objects  in  the  system.  The  engineering  viewpoint  is  not 
concerned  with  semantics  of  the  ODP  application,  except  to  determine  its  requirements 
for  distribution  and  distribution  transparency.  [IS0195]  The  computational  viewpoint  is 
concerned  with  when  and  why  objects  interact,  while  the  engineering  viewpoint  is 
concerned  with  how  they  interact. 

The  fundamental  entities  described  in  the  engineering  viewpoint  are  objects  and 
channels.  Objects  in  the  engineering  viewpoint  can  be  divided  into  two  categories  -  basic 
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engineering  objects  and  infrastructure  objects.  Basic  engineering  objects  correspond  to 
the  objects  in  the  computational  viewpoint.  An  example  of  an  infrastructure  object  is  a 
protocol  object.  A  channel  corresponds  to  a  binding  or  binding  object  in  the 
computational  viewpoint.  A  channel  provides  the  communication  mechanism  and 
contains  or  controls  the  distribution  transparencies.  [IS0395] 

F.  TECHNOLOGY  VIEWPOINT 

The  technology  viewpoint  focuses  on  the  choice  of  technology  for  implementation 
of  the  system.  The  technology  viewpoint  also  describes  the  information  required  for 
testing.  RM-ODP  has  very  few  rules  applicable  to  technology  specifications.  [IS0395] 
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III.  RELATED  WORK 


This  chapter  describes  some  of  the  previous  research  most  closely  related  to  this 
thesis.  The  work  of  seven  groups  of  authors  is  highlighted  in  the  remainder  of  this 
section.  A  separate  section  for  each  group  follows. 

Finkelstein  and  Fuks  propose  a  formal  framework  for  understanding  the  software 
development  process  and  consider  in  particular  software  development  as  cooperative 
work. 

Nuseibeh,  Kramer,  and  Finkelstein  propose  an  object-based  framework  for  the 
development  of  heterogeneous,  composite  systems.  The  framework  uses  viewpoints  that 
represent  agents  having  roles  in  and  views  of  a  problem  domain.  They  also  explore  the 
use  of  inter-viewpoint  rules  to  express  the  relationships  between  different  viewpoints. 

Finkelstein,  Gabbay,  Hunter,  and  Nuseibeh  discuss  the  distributed  development  of 
specifications  from  multiple  perspectives.  The  authors  combine  two  areas  of  research:  1) 
the  viewpoints  framework  for  perspective  development,  interaction,  and  organization  and 
2)  a  logic-based  approach  to  consistency  handling. 

Easterbrook  and  Nuseibeh  discuss  inconsistency  management.  The  authors  use 
viewpoints  to  identify  consistency  relationships,  check  for  inconsistencies,  and  resolve 
conflicts;  these  are  important  steps  in  managing  inconsistency  in  an  evolving 
specification. 
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Kotonya  and  Sommerville  discuss  several  viewpoint-oriented  requirements 
approaches  and  give  a  description  of  an  alternative,  object-oriented,  viewpoint-based 
approach. 

Sibley,  Michael,  and  Wexelblat  discuss  the  use  of  a  policy  workbench  to  aid  in 
analyzing  proposed  policy,  maintain  a  policy  database,  and  assist  in  policy  enforcement. 
The  authors  discuss  the  requirements,  preliminary  design,  and  prototype  implementation 
of  such  a  workbench. 

Lupu  and  Sloman  focus  on  policy  conflicts  and  the  problems  of  conflict  detection 
and  resolution  in  distributed  systems. 

A.  COOPERATIVE  FRAMEWORK 

Finkelstein  and  Fuks  propose  a  formal  framework  for  understanding  the  software 

development  process  and  consider,  in  particular,  software  development  as  cooperative 
work.  The  requirements  for  a  software  development  framework  are  reviewed  and  set  in 
the  context  of  an  established  development  paradigm.  The  underlying  model  of 
cooperation,  based  on  dialogue,  is  motivated  and  outlined.  A  formal  scheme  for 
expressing  this  model  is  introduced  and  the  basic  constructs  are  described.  The  authors 
also  present  a  tool  to  investigate  software  development  in  this  style.  [FINK89] 

The  authors  argue  that  a  framework  is  fundamental  to  organizing  the  development 
of  software  as  an  engineering  activity.  The  authors’  discussion  of  a  cooperative 
framework  is  divided  into  two  parts.  The  first  part  outlines,  from  a  software  engineering 
perspective,  the  requirements  and  intuitions  on  which  their  approach  is  based.  The 
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second  part  presents  and  illustrates  the  basic  elements  of  a  formal  model  of  software 
development.  They  try  to  closely  integrate  the  formal  approach  to  software  development 
with  software  engineering  concerns  such  as  cooperation.  [FINK89] 

The  primary  requirement  for  a  model  of  software  development  is  that  it  be 
cooperative.  Additionally,  the  model  should  not  fail  in  the  presence  of  conflict.  The 
resolution  of  conflicts  should  be  explicitly  controlled  and  organized  as  part  of  the  overall 
process  of  software  development. 

The  authors’  starting  point  of  a  formal  model  is  the  established  paradigm  of 
incremental  refinement.  The  model  is  based  on  dialogue.  The  underlying  vehicle  for 
defining  the  framework  is  a  systematic  model  of  dialogue.  The  model  has  the  following 
components: 

1)  View  -  a  logical  “perspective”  in  the  dialogue  in  which  a  physical  participant 
in  a  dialogue  may  have  multiple  views  or  “perspectives”  that  correspond  with 
organizational  roles 

2)  Commitment  store  -  each  view  has  a  commitment  store  which  holds  its 
commitments  within  its  domain;  e.g.  the  rules 

3)  Board  -  the  medium  of  communication  between  views  which  represents  both 
a  history  of  the  dialogue  and  its  current  state 

4)  Database  -  holds  “facts”  internally  or  privately  to  the  view,  stored  before  the 
start  of  the  dialogue,  and  contains  knowledge,  which  does  not  have  the  full 
status  of  public  engagement 
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5)  Dialogue  engine  -  interprets  the  general  rules  governing  the  dialogue  in  the 
context  of  the  current  dialogue  and  acts  as  the  controller  of  the  dialogue,  on 
the  part  of  the  view  [FENK89] 

The  authors  analyzed  the  model  with  a  case  study  of  an  automated  travel  ticket 
system.  The  authors  believe  that  dialogue  provides  a  basis  for  cooperative  software 
development  framework,  especially  in  the  area  of  defining  requirements.  [FINK89] 

B.  THE  VIEWPOINTS  APPROACH 

Nuseibeh,  Kramer,  and  Finkelstein  discuss  the  problems  of  heterogeneity.  They 
state  that  heterogeneity  in  large  systems  is  inevitable  and  that  no  single  development 
process  or  representation  is  sufficient  for  the  development  of  large  systems. 
Heterogeneity  introduces  problems  of  integration:  1)  integration  of  the  methods  used  to 
specify  system  requirements,  2)  integration  of  the  tools  that  support  these  methods,  and  3) 
integration  of  the  multiple  specification  fragments  produced  by  these  methods  and  tools. 
[NUSE93] 

In  the  development  of  heterogeneous  systems,  the  authors  discuss  a  concept  called 
the  multiple  perspectives  problem,  which  they  define  as  “the  class  of  problems 
surrounding  the  development  of  composite  systems  by  many  development  participants.” 
[NUSE93]  The  authors  use  an  object-based  viewpoints  framework  to  deal  with  the 
problems  of  integration.  They  use  viewpoints  to  describe  the  system  development 
participants,  their  roles  in  the  development  process,  and  their  views  of  the  problem 
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domain.  [NUSE93]  Viewpoints  encapsulate  development  of  systems  into  five  different 
slots: 

1)  Style  -  notation  or  representation  style  used 

2)  Domain  -  describes  the  area  of  concern  of  the  viewpoint  with  respect  to  the 
overall  system  under  development 

3)  Work  plan  -  development  actions  and  strategy  that  use  the  notation  defined  in 
the  style  slot 

4)  Specification  -  describes  the  viewpoint  domain  in  the  notation  described  in 
the  style  slot  and  developed  using  the  strategy  described  in  the  work  plan  slot 

5)  Work  record  -  contains  the  development  state  and  history  of  the  specification 
produced  in  the  specification  slot  and  allows  traceability 

The  authors  define  a  viewpoint  template  as  a  viewpoint  type  in  which  only  the 
style  and  work  plan  slots  have  been  defined.  When  instantiated,  a  viewpoint  template 
becomes  a  viewpoint,  which  can  then  be  expanded  to  produce  the  specification  for  a 
particular  domain.  A  viewpoint  template  is  therefore  a  reusable  description  of  a 
development  technique,  which  can  be  instantiated  many  times  to  produce  different 
viewpoints. 

The  style  slot  of  each  template  may  be  represented  in  terms  of  objects  and 
relations,  with  each  having  attributes  with  types  and  values.  The  work  plan  slot  has  four 
generic  categories  of  development  actions: 

1)  Assembly  actions  -  the  basic  actions  required  to  build  (assemble)  a 
specification  in  the  current  representation  style 
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2)  In-viewpoint  check  actions  -  actions  that  can  be  performed  to  check  that  a 
specification  is  syntactically  consistent 

3)  Inter-viewpoint  check  actions  -  actions  that  can  be  performed  to  check  the 
consistency  between  (overlapping  and  interacting)  specifications  residing  in 
different  viewpoints  and  may  also  be  used  to  transfer  information  between 
viewpoint  specifications 

4)  Viewpoint  trigger  actions  -  actions  that  must  be  performed  in  order  to  create 
new  viewpoints  (instantiated  viewpoint  templates) 

The  authors  attempt  to  integrate  multiple  requirements  specification  viewpoints. 
In  doing  so,  they  state  that  overlaps  must  be  identified  and  expressed,  complementary 
participants  must  interact  and  cooperate,  and  contradictions  must  be  resolved.  The 
authors  address  Inter-viewpoint  communication  as  a  vehicle  for  viewpoint  integration. 
The  authors  argue  that  “successful  inter-viewpoint  communication  holds  the  key  to 
achieving  integration  in  a  heterogeneous,  possibly  distributed,  setting.”  There  is  a  need  to 
express  relationships  between  viewpoints,  enact  these  relationships  (check  consistency 
and  transfer  or  transform  information),  and  resolve  conflicts  (if  and  when  it  is  necessary 
to  do  so).  [NUSE93] 

During  development  the  different  viewpoint  specifications  may  be  overlapping 
and/or  inconsistent  with  each  other.  Inconsistency  is  tolerated  in  the  viewpoints  approach 
and  not  checked  or  corrected  except  as  needed.  Inter-viewpoint  rules  are  then  defined  to 
check  consistency  and  transfer  and  transform  information  between  viewpoint 
specifications.  The  rules  describe  the  relationships  and  specify  when  they  may  be 
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invoked  and  how  they  should  be  applied.  The  rules  are  defined  in  the  viewpoint  template 
work  plans  and  describe  relationships  between  viewpoints  that  have  not  yet  been  created. 
The  authors  define  the  rules  in  great  detail.  The  inter-viewpoint  rules  are  invoked  by  the 
owner  (development  participant)  of  the  viewpoint  in  which  they  reside.  The  authors 
discuss  three  approaches  to  rules  invocation: 

1)  “The  constrained”  -  in  which  rules  are  constantly  invoked 

2)  “Pragmatic”  -  in  which  rule  invocation  may  be  turned  on  and  off  by  the  user 

3)  “Process-oriented”  -  in  which  the  process  model  of  the  viewpoints  guides 
rules  invocation  [NUSE94] 

The  authors  state  that  “ideally,  a  method  designer  would  be  provided  with  a 
predefined  library  of  relationships  at  his/her  disposal,  with  the  option  of  defining  any 
further  relationships  if  required.”  [NUSE94]  There  are  two  modes  of  application  of  an 
inter- viewpoint  rule: 

1)  Check  Mode  -  in  which  the  relationship  question  is  asked  (does  the 
relationship  hold  between  the  two  viewpoints?).  The  relationship  either  holds 
or  conflict  resolution  must  be  performed  to  make  it  hold. 

2)  Transfer  Mode  -  in  which  the  function  is  applied  to  transfer  and  transform 
information  from  one  viewpoint  to  another  so  that  the  relation  will  hold 
between  them.  [NXJSE94] 

An  invoked  inter-viewpoint  rule  is  normally  applied  in  “check  mode”  to  begin 
with,  after  which  a  “transfer  mode”  may  be  entered  into  if  the  rule  failed.  Information 
transfer  is  viewed  as  a  form  of  conflict  resolution. 
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The  authors  use  a  generic  computer-based  prototype  environment  called  The 
Viewer  to  support  the  viewpoints  framework.  The  Viewer  provides  tools  for  viewpoint 
construction  and  deployment.  [NUSE92] 

C.  INCONSISTENCY  HANDLING 

Finkelstein,  Gabbay,  Hunter,  and  Nuseibeh  discuss  the  distributed  development  of 
specifications  from  multiple  perspectives.  Using  multiple  perspectives  leads  to  problems 
of  identifying  and  handling  inconsistencies  between  perspectives.  The  authors  combine 
two  areas  of  research:  1)  the  viewpoints  framework  for  perspective  development, 
interaction,  and  organization  and  2)  a  logic-based  approach  to  consistency  handling. 
[HNK94] 

The  authors  do  not  believe  that  it  is  possible  to  maintain  absolute  consistency 
between  perspectives  at  all  times.  It  is  often  undesirable  to  enforce  consistency, 
“particularly  when  this  constrains  the  specification  unnecessarily  or  entails  loss  of  design 
freedom  by  enforcing  an  early  resolution.”  [FINK94] 

The  authors  provide  an  overview  of  inconsistency  handling  using  the  viewpoints 
framework.  The  authors  also  illustrate  and  discuss  the  identification  and  handling  of 
inconsistency  using  simple  library  system  example.  They  believe  that  inconsistency 
handling  should  be  based  on  logic.  They  state  that  “the  problem  of  inconsistency 
handling  in  the  viewpoints  framework  can  then  be  viewed  as  being  equivalent  to 
inconsistency  handling  in  distributed  logical  databases.”  [FTNK94] 
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D.  INCONSISTENCY  MANAGEMENT  WITH  VIEWPOINTS 


Easterbrook  and  Nuseibeh  discuss  inconsistency  management.  The  authors  state 
that  “inconsistency  is  important  in  the  software  specification  process,  because,  on  the  one 
hand,  inconsistent  specifications  cannot  be  satisfied,  whereas  on  the  other,  it  is  hard  to 
achieve  consistency  in  a  large  specification  written  by  a  team.”  [EAST96]  They  believe 
that  proper  management  of  inconsistencies  lead  to  a  more  robust  specification,  because 
inconsistencies  provide  important  clues  about  missing  information.  They  show  that 
viewpoints  can  be  used  as  the  cornerstone  of  effective  inconsistency  management. 
[EAST96] 

They  define  inconsistency  to  be  “any  situation  in  which  two  parts  of  a 
specification  do  not  obey  some  relationship  that  should  hold  between  them.”  [EAST96] 
Inconsistency  classification  focuses  on  identifying  the  kind  of  inconsistency  that  has  been 
detected  in  a  specification.  Inconsistencies  are  classified  in  two  ways:  1)  according  to 
cause,  the  result  of  mistakes  such  as  typographic  error  or  conceptual  disagreements  and  2) 
into  different  predefined  kinds  of  inconsistency  that  may  arise  in  programming. 

The  authors  define  five  ways  of  dealing  with  inconsistencies: 

1)  Ignore  -  appropriate  if  inconsistency  is  isolated  and  does  not  prevent  further 
development,  or  the  level  of  risk  does  not  justify  fixing  it 

2)  Delay  -  used  when  further  information  is  required,  but  is  not  immediately 
available 

3)  Circumvent  -  used  to  disable  or  modify  the  rule  that  was  broken  to  get  around 
the  inconsistency 
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4)  Ameliorate  -  appropriate  when  steps  are  needed  to  improve  the  situation  but 
not  necessarily  remove  the  inconsistency,  also  called  incremental  resolution 

5)  Resolve  -  used  to  repair  the  inconsistency  immediately  [EAST96] 

An  inconsistency  implies  missing  information.  Inconsistency  management 
provides  a  route  to  improved  understanding  of  requirements.  A  key  problem  is  tracking 
known  inconsistencies  and  recording  development  information. 

They  base  their  work  on  a  framework  for  distributed  software  engineering,  in 
which  multiple  perspectives  are  maintained  separately  as  distributable  objects  called 
viewpoints,  which  are  defined  in  [NUSE92],  [NUSE93],  and  [NUSE94].  The  framework 
is  independent  of  any  software  development  method. 

In  the  authors’  framework,  there  is  no  requirement  for  changes  to  one  viewpoint 
to  be  consistent  with  other  viewpoints.  [EAST96]  Inconsistencies  are  tolerated 
throughout  the  software  development  process.  They  focus  on  the  management  of 
inconsistencies.  Consistency  checking  and  resolution  are  still  required,  but  they  are 
delayed  until  an  appropriate  time.  To  manage  inconsistencies,  the  relationships  between 
viewpoints  are  clearly  defined.  Consistency  checking  is  performed  by  applying  a  set  of 
rules  which  express  the  relationships;  these  rules  should  hold  between  particular 
viewpoints. 

The  authors’  use  state  transition  diagrams  to  specify  the  required  behavior  of  a 
device.  The  method  permits  partitioning  of  the  state  transition  diagram  describing  a 
single  device  into  separate  viewpoints,  such  that  the  union  of  all  of  the  viewpoints 
describes  all  of  the  states  and  transitions  of  the  device.  [EAST96] 


24 


The  method  provides  the  following: 

1)  The  notation  for  expressing  states  and  transitions  diagrammatically 

2)  A  partitioning  step  that  allows  a  separate  diagram  to  be  created  to  represent  a 
subset  of  the  behaviors  of  a  particular  device 

3)  A  set  of  consistency  checking  rales  which  test  whether  partitioned  diagrams 
representing  the  same  device  are  mutually  consistent 

4)  An  analysis  step  that  allows  two  viewpoints  to  be  treated  as  separate  devices 
that  interact 

5)  A  further  set  of  consistency  checking  rales  which  test  whether  interacting 
devices  whose  transitions  have  been  linked  together  exhibit  consistent 
behaviors 

The  authors  also  discuss  The  Viewer,  a  prototype  computer-based  environment 
and  associated  tools  (discussed  in  Nuseibeh,  Kramer,  and  Finkelstein’s  work),  which  has 
been  constructed  to  support  the  viewpoints  framework.  The  Viewer  has  two  distinct 
modes  of  use:  method  design  and  method  use.  Method  design  involves  creation  of 
viewpoint  templates;  these  are  viewpoints  for  which  only  the  representation  style  and 
work  plan  slots  are  defined.  In  method  use,  viewpoints  are  instantiated  from  the 
templates  to  represent  the  various  perspectives.  Each  viewpoint  is  a  self-contained 
specification  development  tool.  The  Consistency  Check  in  The  Viewer  allows  users  to 
invoke  and  apply  in-  and  inter- viewpoint  consistency  rales  and  record  the  results  of  all  the 
checks  in  the  work  record  of  the  affected  viewpoint.  [EAST96] 
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The  authors  state  that  viewpoints  facilitate  separation  of  concerns  and  the 
partitioning  of  software  development  knowledge.  [EAST96]  Partitioning  is  only  useful  if 
relationships  and  dependencies  between  partitions  can  be  defined.  The  authors  showed 
how  relationships  could  be  defined  as  part  of  a  collection  of  viewpoints.  They  also 
demonstrated  how  inconsistencies  identified  by  checking  relationships  could  be  resolved. 
According  to  the  authors,  identifying  consistency  relationships,  checking  inconsistency 
and  resolving  conflicts  are  all  important  steps  in  managing  inconsistency  in  an  evolving 
specification.  [EAST96] 

E.  OBJECT-ORIENTED  VIEWPOINT-BASED  APPROACH 

Kotonya  and  Sommerville  discuss  several  viewpoint-oriented  requirements 
approaches  and  give  a  description  of  an  alternative  object-oriented  viewpoint-based 
approach.  They  use  an  automated  teller  machine  (ATM)  case  study  to  analyze  the  various 
approaches. 

The  authors  state  that  the  “task  of  modeling  a  user’s  needs  involves  the  capture, 
analysis  and  resolution  of  many  ideas,  perspectives  and  relationships  at  varying  levels  of 
detail.”  [K0T092]  The  authors  have  developed  a  two-layered  approach  to  system 
modeling.  The  first  layer,  the  viewpoint  layer,  is  concerned  with  “identifying  relevant 
viewpoint  entities  in  the  system  environment  and  associating  them  with  the  services  they 
require.”  The  second  layer,  the  system  layer,  is  concerned  with  “identifying  system 
entities  responsible  for  the  provision  of  services  to  the  viewpoint  layer.”  In  their  research, 
the  authors  only  discuss  the  viewpoint  layer.  [K0T092] 
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The  authors  discuss  and  analyze  six  viewpoint-oriented  approaches  developed  by 
other  researchers,  which  include: 

1)  Structured  Requirements  Definition  (SRD) 

2)  Structured  Analysis  and  Design  Technique  (SADT) 

3)  Controlled  Requirements  Expression  (CORE) 

4)  Viewpoints-Oriented  Software  Development  (VOSD) 

5)  Viewpoint  Analysis 

6)  Other  Methods 

1.  Structured  Requirements  Definition  (SRD) 

SRD  is  based  on  “defining  the  application  context.”  [K0T092]  It  consists  of  a 
four-step  process: 

1)  Define  a  user-level  data-flow  diagram  by  interviewing  each  individual  in  the 
organization  to  be  analyzed  who  currently  performs  some  useful  task.  Record 
the  input/output  as  a  data-flow  model. 

2)  Combine  all  like  user-level  data-flow  diagrams  to  create  one  integrated  data¬ 
flow  diagram.  Conflicting  data  can  be  resolved  at  this  stage. 

3)  Define  the  application-level  data-flow  diagram  by  drawing  a  dotted  line 
around  the  part  of  the  combined  user  data-flow  diagram  that  corresponds  to 
the  organization  being  analyzed. 

4)  Define  the  application-level  functions  by  showing  the  order  that  comprises 
each  function  being  performed  by  the  organization  being  modeled. 
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SRD  viewpoints  are  individuals  in  the  organization  being  specified  that  are 
manually  performing  a  function  which  will  be  automated.  SRD  does  not  work  well  if  the 
system  being  specified  does  not  involve  the  automation  of  several  manual  tasks. 

Kotonya  and  Sommerville  list  the  shortcomings  of  the  SRD  approach.  They  state 
that  SRD  has  an  intuitive,  rather  than  defined,  notion  of  a  viewpoint,  making  it  the 
secondary  rather  than  primary  technique  used  in  the  methodology.  The  authors  also  state 
that  “viewpoint  analysis  does  not  extend  beyond  data  sourcing  and  sinking  in  SRD.” 
[K0T092] 

2.  Structured  Analysis  and  Design  Technique  (SADT) 

SADT  is  based  on  a  data-flow  model  that  views  a  system  as  a  set  of  activities.  “A 
rectangular  box  representing  the  system’s  most  abstract  activity,  together  with  a  set  of 
data  input,  data  output  and  control  arrows,  forms  the  starting  point  for  functional 
decomposition.”  [KOT092]  Consistency  checking  involves  “matching  the  set  of  inputs 
and  outputs  at  each  successive  functional  level  with  the  higher  function.”  [K0T092] 

The  authors  also  discuss  the  shortcoming  of  SADT.  Like  SDR,  the  SADT 
viewpoint  is  not  defined;  it  is  an  intuitive  extension  of  the  underlying  modeling 
technique.  SADT  viewpoints  are  also  not  analyzed  beyond  being  seen  as  data  sources 
and  sinks.  SADT  does  not  provide  a  framework  for  control  information  between 
viewpoints. 

3.  Controlled  Requirements  Expression  (CORE) 

CORE  is  a  functional  requirements  definition  method  based  on  a  viewpoint 
approach.  It  is  one  of  the  few  requirements  definition  methods  that  explicitly  uses  a 
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viewpoint  approach.  CORE  defines  viewpoints  at  two  levels.  The  first  level  consists  of 
all  entities  that  interact  or  affect  the  system  in  some  way.  The  second  level  is  concerned 
with  distinguishing  between  defining  and  bounding  viewpoints.  “Bounding  viewpoints 
are  entities  that  interact  indirectly  with  the  system,  whereas  defining  viewpoints  are  sub¬ 
processes  of  the  system,  viewed  in  a  top-down  manner.”  [K0T092] 

The  CORE  methodology  consists  of  steps:  1)  viewpoint  identification,  2) 
viewpoint  structuring,  3)  tabular  collection,  4)  data  structuring,  5)  single  viewpoint 
modeling,  6)  combined  viewpoint  modeling,  and  7)  constraints  analysis. 

In  step  1,  the  viewpoint  identification  step,  functional  and  non-functional 
viewpoints  are  identified.  Step  2,  the  viewpoint  structuring  step,  provides  a  framework 
for  requirements  capture  and  analysis.  It  involves  iterative  decomposition  of  the  system 
into  a  hierarchy  of  functional  sub-systems,  using  a  top-down  decomposition.  Step  3,  the 
tabular  collection  step,  is  a  mechanism  for  gathering  information  about  a  viewpoint. 
Each  viewpoint  is  considered  with  respect  to  the  following:  1)  the  action  it  performs,  2) 
the  input  data  used  for  these  actions,  3)  the  output  data  derived,  4)  the  sources  of  the  data, 
and  5)  the  destinations  of  the  data.  Tabular  collections  are  required  to  resolve  omissions 
and  conflicts  in  information  across  viewpoints.  Steps  4  through  7  are  not  discussed  in 
detail  in  the  authors’  work. 

Kotonya  and  Sommerville  state  that  the  major  weakness  in  CORE  is  its  poorly 
defined  notion  of  a  viewpoint.  Since  the  CORE  viewpoint  can  be  any  entity  that  interacts 
with  the  system,  it  is  difficult  to  say  what  is  and  is  not  a  valid  viewpoint. 
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4. 


Viewpoints-Oriented  Software  Development  (VOSD) 

In  viewpoints-oriented  software  development  (VOSD),  Finkelstein  proposed  the 
use  of  viewpoints  as  a  way  of  managing  the  software  development  process.  VOSD  uses 
viewpoints  to  “capture  the  role  and  responsibility  performed  by  a  participant  at  a 
particular  stage  of  the  software  development  process.  Viewpoints  are  identified  by  the 
role  of  the  participant,  the  domain  relevant  to  their  interest  and  the  knowledge  about  the 
domain.”  [K0T092]  A  viewpoint  is  a  combination  of  a  style  or  representation  scheme  in 
which  the  viewpoint  expresses  what  it  sees,  the  domain  it  sees,  a  specification,  a  work 
plan  that  defines  the  conditions  under  which  the  specification  can  be  changed,  and  a  work 
record.  A  template  is  defined  as  a  viewpoint  with  only  the  style  and  work  plan. 
[KOTO92]  Viewpoints  are  discussed  in  greater  detail  in  section  B  of  this  chapter. 

VOSD  is  both  a  “requirements  approach  and  an  approach  to  facilitate  distributed 
software  development.”  [KOT092]  According  to  Kotonya  and  Sommerville,  VOSD 
fails  to  provide  a  firm  framework  for  resolving  the  conflicts  between  representations  that 
have  little  correspondence.  They  also  state  that  VOSD  provides  no  obvious  way  of 
integrating  functional  and  non-functional  requirements  and  capturing  the  different  classes 
of  entities. 

5.  Viewpoint  Analysis 

Leite  uses  a  viewpoints  resolution  approach  as  a  means  for  early  validation  in  the 
process  of  requirements  elicitation.  [K0T092]  The  objective  is  to  identify  and  classify 
problems  related  to  correctness  and  completeness.  Leite  defines  a  viewpoint  as  “standing 
or  mental  position  used  by  an  individual  when  examining  a  universe  of  discourse  (the 
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overall  context  in  which  the  software  will  be  developed,  including  all  the  sources  of 
information  and  the  people  involved).”  [K0T092]  A  perspective  is  defined  as  “a  set  of 
facts  observed  and  modeled  according  to  a  particular  aspect  of  reality.”  [K0T092] 

Viewpoint  analysis  uses  three  modeling  aspects:  the  data  perspective,  the  actor 
perspective,  and  the  process  perspective.  A  view  is  defined  as  an  integration  of  these 
perspectives.  View  integration  is  achieved  by  a  view-construction  process.  [K0T092] 

Leite  uses  a  viewpoint  language  (VWPL)  to  represent  the  viewpoints.  Kotonya 
and  Sommerville  state  that  Leite  associates  viewpoints  with  the  roles  of  the  people  in 
analyzing  the  problem  domain.  They  also  state  that  VWPL  is  not  a  requirements 
language  and  that  “its  main  objective  is  to  register  early  results  of  the  fact  elicitation 
process  in  the  requirements  exercise.”  [K0T092] 

6.  Other  Methods 

Kotonya  and  Sommerville  also  discuss  two  other  approaches  to  requirements 
definition.  Van  Lamsweerde,  Fickas,  and  Dardenne  use  a  goal-directed  approach  to 
resolve  conflicts  and  develop  multiple  viewpoints.  Dubios,  Hagelstein,  and  Rifuat 
developed  an  approach  that  focuses  on  the  larger  system  formed  by  the  computer  and  its 
environment,  rather  than  on  the  required  system  software.  [K0T092] 

Kotonya  and  Sommerville  do  not  view  Van  Lamsweerde,  Fickas,  and  Dardenne’s 
approach  or  Dubios,  Hagelstein,  and  Rifuat’s  approach  as  viewpoint  oriented  and, 
therefore,  do  not  discuss  them  in  detail. 
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7.  Viewpoint-oriented  Analysis  (VOA) 

Kotonya  and  Sommerville  discuss  their  approach,  which  is  an  object-oriented 
viewpoint-based  approach  to  requirements  definition  called  viewpoint-oriented  analysis 
(VOA).  “VOA  extends  and  enriches  the  traditional  data-sink/source  orientation  of 
current  viewpoint  approaches  to  incorporate  aspects  of  viewpoint  classification  and 
different  modes  of  interaction.”  [K0T092]  The  VOA  framework  supports: 

1)  Requirements  capture  and  resolution 

2)  Classifying  and  analyzing  viewpoint-system  interaction 

3)  Integrating  functional  and  non-functional  aspects  of  requirements 

VOA  supports  the  identification  of  key  system  objects,  their  attributes,  and  their 
methods.  The  authors  focus  on  the  viewpoint  layer.  VOA  includes  four  main  stages:  1) 
viewpoint  identification,  2)  viewpoint  structuring  and  decomposition,  3)  information 
collection,  and  4)  reconciliation  of  information  across  viewpoints.  [KOT092] 

VOA  identifies  a  viewpoint  as  “an  external  entity  that  interacts  with  the  system 
being  analyzed,  but  one  that  can  exist  without  the  presence  of  the  system.”  [K0T092] 
Viewpoints  fall  into  two  classes: 

1)  Active  viewpoints  -  entities  that  initiate  some  form  of  interaction  between 
themselves  and  the  system  either  by  requesting  services  or  providing  control 
information  to  the  system. 

2)  Passive  viewpoints  -  essentially  data  stores  or  sinks.  Any  interaction  between 
them  and  the  system  is  initiated  by  the  system. 
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Control  information  defines  and  describes  how  the  environment  controls  the 


system  and  how  the  system  controls  the  environment.  In  VOA,  there  are  two  levels  of 
control,  the  viewpoint  level  and  the  system  level.  At  the  viewpoint  level,  controls  are 
concerned  with  “the  description  of  signals  to  start  and  stop  specific  services.”  [K0T092] 
At  the  system  level,  controls  are  concerned  with  “associating  control  information 
described  at  the  viewpoint  level  with  entities  in  the  system  responsible  for  the  provision 
of  services.”  [K0T092] 

Viewpoint  structuring  provides  the  engineer  with  a  tool  for  splitting  the  analytic 
tasks  associated  with  viewpoints  into  a  number  of  specification  levels.  A  viewpoint  is  a 
hierarchy  with  differing  levels  of  abstraction  or  specialization.  The  top  level  contains  the 
most  abstract  description,  and  the  lowest  is  most  specialized.  Each  lower  level  inherits 
the  services,  attributes,  control  information,  and  non-functional  constraints  of  the  more 
abstract  viewpoints.  The  sub-viewpoints  may  have  their  own  constraints  on  inherited 
services  and  may  also  have  their  own  particular  service  requirements. 

VOA  uses  standard  forms  to  collect  information  associated  with  a  viewpoint. 
Information  reconciliation  is  used  “to  ensure  that  all  the  required  services  are  provided 
for,  and  that  omissions  or  conflicting  information  can  be  identified  and  problems 
resolved.”  [K0T092]  According  to  Kotonya  and  Sommerville,  VOA  provides  a 
powerful  framework  for  integrating  functional  and  non-functional  aspects  of 
requirements. 


33 


F.  POLICY  WORKBENCH 

Sibley,  Michael,  and  Wexelblat  discuss  the  use  of  a  policy  workbench  to  aid  in 
analyzing  proposed  policy,  maintain  a  policy  database,  and  assist  in  policy  enforcement. 
The  authors  discuss  the  requirements,  preliminary  design,  and  prototype  implementation 
of  such  a  workbench.  The  objective  of  their  research  was  to  demonstrate  computer 
support  for  a  policy  maker,  enforcer,  and  user.  The  authors  state  that  policy  is  often 
embedded  in  a  system.  [SBBL92] 

The  following  are  the  requirements  for  a  general  policy  workbench: 

1)  “The  workbench  outputs  must  be  understandable  by  almost  anybody  with  the 
domain  knowledge  in  which  the  system  is  to  be  used.”  [SEBL92] 

2)  ‘The  underpinnings  of  the  policy  representation  must  be  based  on  appropriate 
formalisms  but  not  be  domain  specific.”  [SIBL92] 

The  authors  define  five  classes  of  people  who  need  to  deal  with  organizational 
policy:  1)  policy  maker,  2)  policy  maintainer,  3)  policy  implementer,  4)  policy  enforcer, 
and  5)  policy  user  or  designer  of  a  system. 

One  of  the  requirements  for  a  policy  workbench  is  “the  ability  to  represent  policy 
in  a  way  that  can  be  supported  by  formal  analysis.”  [SIBL92]  They  discuss  possible 
problems  in  policy  representation: 

1)  Tend  to  be  abstract  and  stated  in  imprecise  language 

2)  Are  often  incomplete  and  inconsistent 

3)  Are  often  interdependent  and  nested 

4)  May  be  very  large 
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5)  Need  to  represent  time  as  an  important  component 

6)  Require  a  statement  of  intent  to  be  fully  representable 

7)  Fall  along  a  wide  spectrum  of  scope,  from  general  to  specific  [SEBL92] 

The  policy  workbench  is  comprised  of  the  following  three  tools  [SIBL92]: 

1)  “A  theorem  and  assertion  analyzer  [entering  and  exercising  policy]  to  check 
inputs,  stated  as  axioms  and  theorems” 

2)  “A  rule  compiler-generator-interpreter  [selecting,  merging  and  generating 
parts  of  systems]  to  produce  an  executable  component  of  the  system” 

3)  “An  interactive  policy  structurer  and  selector  [aiding  in  understanding  and 
applying  policy]  to  check  what  rules  are  applicable  to  a  given  situation  and 
preprocessing  the  rules  into  pre-  and  post-conditions” 

The  authors  placed  emphasis  on  “developing  and  experimenting  with  a  prototype 
policy  workbench  that  supports  each  software  development  phase.”  [SEBL92] 

G.  CONFLICTS  IN  POLICY-BASED  DISTRIBUTED  SYSTEMS 

Lupu  and  Sloman  focus  on  policy  conflicts  and  the  problems  of  conflict  detection 
and  resolution.  Distributed  systems  contain  a  large  number  of  objects.  New  components 
and  services  are  added  and  removed  from  the  system  dynamically,  which  changes  the 
requirements  of  the  management  system  over  its  lifetime.  [LUPU97] 

The  authors  state  that  policies  are  a  means  of  specifying  and  influencing 
management  behavior  within  a  distributed  system,  without  coding  the  behavior  into  the 
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management  agents.  The  authors’  approach  is  aimed  at  specifying  implementable 
policies.  They  define  two  types  of  policies: 

1)  Authorization  policies  -  security  policies  related  to  access  control  and  specify 
what  activities  a  subject  is  permitted  or  forbidden  to  do  to/with  a  set  of  target 
objects 

2)  Obligation  policies  -  specify  what  activities  a  subject  must  or  must  not  do  to  a 
set  of  target  objects  and  define  the  duties  of  the  policy  subject 

The  authors  permit  specification  of  both  positive  and  negative  authorization 
policies  and  require  explicit  authorization.  They  state  that  conflicts  can  arise  in  the  set  of 
policies  due  to  omissions,  errors,  or  conflicting  requirements  of  the  administrators 
specifying  the  policies.  For  example,  an  obligation  policy  may  define  an  activity  a 
manager  must  perform,  but  there  is  no  authorization  policy  to  permit  the  manager  to 
perform  the  activity.  Conflicts  can  also  arise  between  positive  and  negative  policies 
applying  to  the  same  objects.  Whenever  multiple  policies  apply  to  an  object,  there  is  the 
potential  for  some  form  of  conflict,  but  multiple  policies  are  essential.  Many  policies 
specified  for  the  management  of  a  large  system  specify  exceptions  to  more  general 
policies.  The  system  may  have  to  resolve  conflicts  such  as  exceptions  to  normal 
authorization  policies.  A  precedence  relationship  is  established  between  policies  to 
resolve  conflicts. 

The  authors  use  roles  as  the  mean  of  grouping  policies  related  to  a  particular 
manager  position.  Then  managers  can  be  assigned  or  removed  from  the  position  without 
changing  the  policies.  They  also  define  the  relationships  between  roles  with  regard  to  the 
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use  of  shared  resources  or  with  regard  to  organizational  structure.  The  authors  use  roles 
and  inter-role  relationships  to  provide  a  scope  for  the  conflict  detection  and  help  to  limit 
the  number  of  policies  that  must  be  examined  in  order  to  detect  conflicts.  They  focus  on 
techniques  and  tool  support  for  off-line  (static)  detection  and  resolution,  although  some 
conflicts  can  be  detected  only  at  run-time  (dynamic).  [LUPU97] 

The  authors  state  that  policies  are  interpreted  by  automated  manager  agents,  so  the 
behavior  of  the  agents  can  be  modified  dynamically  by  changing  policy  rather  than  re¬ 
coding.  Obligation  policies  can  be  either  used  in  conjunction  with  authorizations  in  order 
to  ensure  the  integrity  of  the  system  or  to  specify  the  actions  a  component  must  initiate  in 
response  to  changes  in  its  internal  state  or  environment.  [LUPU97] 

The  authors  discuss  the  details  of  the  domains,  policies,  and  roles,  which  form 
their  management  framework.  They  also  discuss  the  types  of  inconsistencies  and  the 
policy  conflicts  that  they  need  to  detect.  Next  they  explain  their  approach  to  conflict 
detection  and  conflict  resolution  based  on  policy-precedence  relationships.  [LUPU97] 

The  authors  state  that  domains  are  used  to  partition  objects  in  a  large  system 
according  to  geographical  boundaries,  object  type,  management  functionality, 
responsibility,  and  authority.  Domains  may  also  be  used  to  group  objects  in  order  to 
apply  a  common  policy  to  a  set  of  objects.  A  sub-domain  is  a  domain  which  is  a  member 
of  another  domain  or  parent  domain.  [LUPU97] 

The  authors  discuss  in  detail  the  notation  used  to  specify  policies.  Authorization 
(A)  and  Obligation  (O)  policies  may  be  positive  or  negative.  The  authors  also  provide 
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some  example  policies  and  show  how  conflicts  can  occur  due  to  positive  and  negative 
policies.  [LUPU97] 

They  define  modality  conflicts  as  inconsistencies  in  the  policy  specification  which 
can  occur  when  two  or  more  policies  with  modalities  of  opposite  sign  refer  to  the  same 
subjects,  actions,  and  targets.  There  are  three  types  of  modality  conflicts: 

1)  0+/0-:  the  subjects  are  both  required  to  and  required  not  to  perform  the  same 
actions  on  the  target  objects 

2)  A+/A-:  the  subjects  are  both  authorized  and  forbidden  to  perform  the  actions 
on  the  target  objects 

3)  O+/A-:  the  subjects  are  required  but  forbidden  to  perform  the  actions  on  the 
target  objects;  obligation  does  not  imply  authorization 

The  authors  focus  their  attention  on  a  static  conflict  detection  tool,  which  assists 
the  users  in  specifying  policies,  roles,  and  relationships.  They  discuss  some  principles  for 
the  detection  of  modality  conflicts  and  present  an  implementation  of  the  conflict  detection 
tool. 

They  propose  that  using  a  policy  precedence  relationship  can  reduce  the  number 
of  conflicts  between  policies  and  permit  inconsistent  specifications.  The  following  are 
the  principles  for  establishing  precedence: 

1)  Negative  policies  always  have  priority 

2)  Assigning  explicit  priorities 
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3)  Distance  between  a  policy  and  the  managed  objects  -  priority  is  given  to  the 
policy  applying  to  the  closer  class  in  the  inheritance  hierarchy  when  evaluating 
access  to  an  object  reference  in  a  query 

4)  Specificity  related  to  domain  nesting  -  can  be  used  within  conflict  detection  to 
reduce  the  number  of  potential  conflicts 

The  authors  state  that  modality  conflicts  can  be  detected  purely  by  syntactic 
analysis  of  the  policies.  Application-specific  conflicts  arise  from  the  semantics  of  the 
policy  and  are  specified  in  terms  of  constraints  on  attribute  values  of  permitted  policies; 
they  call  these  meta-policies.  The  authors  use  a  prototype  conflict  detection  tool  to  detect 
overlaps  between  policies  and  optionally  apply  domain  nesting-based  precedence. 
[LUPU97] 

The  authors  found  that  assigning  positive  or  negative  policies  were  limiting  and 
not  as  intuitive  as  the  precedence-based  approach  on  specificity.  They  actually  only 
implement  positive  authorizations  and  remove  negative  authorizations  by  refinement  of 
the  policies.  They  assume  all  actions  are  prohibited  unless  explicitly  authorized.  Their 
policies  are  not  global;  the  policies  are  interpreted  by  explicitly  specified  subjects  (for 
obligations)  and  targets  (for  authorization).  [LUPU97] 

The  authors  discuss  Sibley,  Michael,  and  Wexelblat’s  Policy  Workbench.  They 
state  that  the  Policy  Workbench  uses  automated  tools  to  specify  and  analyze  policies. 
The  authors  state  that  this  approach  is  complex  due  to  the  generality  of  their  policies.  The 
Policy  Workbench  is  not  based  on  precedence  relationships. 
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In  summary,  Lupu  and  Sloman  presented  the  integration  of  a  conflict  detection 
tool  in  a  role  and  policy-based  framework.  They  performed  off-line,  static  analysis  of  a 
set  of  policies  to  determine  two  types  of  conflicts: 

1)  Modality  conflicts  -  arising  from  positive  and  negative  policies,  which  can  be 
checked  by  analyzing  the  syntax  of  the  policies 

2)  Application  specific  conflicts  -  need  to  be  expressed  by  external  constraints  or 
meta-policies 

They  make  use  of  precedence  relationship  based  on  the  specificity  of  the  policies 
with  respect  to  domain  nesting  to  reduce  the  number  of  potential  overlaps  indicated  to  a 
user  and  allow  inconsistencies  between  policies  to  exist  within  a  system.  The  authors 
implemented  a  prototype  role  framework  which  supports  distributed  policy  and  domain 
servers  and  analysis  of  a  set  of  policies.  Their  approach  is  “to  detect  as  many  conflicts  as 
possible  at  time  of  specification,  rather  than  leaving  them  to  be  detected  at  run-time.” 
[LUPU97]  The  user  can  then  modify  the  policies  to  remove  conflicts.  The  authors 
implemented  their  approach  using  a  CORBA-based  distributed  programming 
environment. 

The  authors  concentrated  on  the  static  analysis  of  policies.  They  stated  that  an 
area  needing  more  research  is  dynamic  run-time  conflict  detection.  Some  constraints  can 
only  be  evaluated  at  run-time,  since  they  depend  on  object  states  or  current  time. 
[LUPU97] 
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IV.  OVERVIEW  OF  THE  BALLISTIC  MISSILE  DEFENSE  SYSTEM 


A.  MOTIVATION 

Ballistic  missiles  have  been  a  threat  to  the  U.S.  and  its  military  operations  for  over 
fifty  years.  The  global  proliferation  of  ballistic  missile  technology  and  weapons  of  mass 
destruction  is  one  of  the  most  immediate  and  dangerous  threats  to  U.S.  national  security 
in  the  post-Cold  War  era.  The  proliferation  of  short-range  ballistic  missiles  in  the  world 
today  poses  a  direct,  immediate  threat  to  many  of  our  allies  and  to  some  U.S.  forces 
deployed  abroad  in  defense  of  our  national  interests.  Over  time,  the  proliferation  of 
longer-range  missiles  could  pose  a  greater  threat  to  the  U.S.  itself.  [MOSH97] 

The  U.S.  has  already  witnessed  the  willingness  of  countries  to  use  theater-class 
ballistic  missiles  for  military  purposes;  e.g.,  the  use  of  Scuds  during  the  Gulf  War.  Since 
1980,  ballistic  missiles  have  been  used  in  six  regional  conflicts.  Strategic  ballistic 
missiles,  including  intercontinental  and  submarine  launched  ballistic  missiles  (ICBMs 
and  SLBMs),  exist  in  abundance  in  the  world  today.  There  is  also  great  concern  from  the 
emergence  of  a  Third  World  long-range  missile  threat  to  the  United  States. 
[BMDOLINK] 

Ballistic  Missile  Defense  (BMD)  plays  a  central  role  in  U.S.  national  security 
strategy  by  supporting  its  defense  and  counterproliferation  objectives.  [BMDOLINK] 
The  requirement  for  BMD  stems  from  a  strategy  that  requires  the  U.S.  to  maintain  an 
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overseas  presence  and  the  capability  to  respond  to  major  regional  conflicts  despite  the 

increasing  danger  posed  by  the  proliferation  of  ballistic  missiles. 

In  a  world  of  regional  threats  to  the  U.S.,  BMD  affords  the  U.S.  greater 
freedom  of  action  to  protect  its  interests  and  uphold  its  security 
commitments  without  fear  of  coercion.  BMD  can  bolster  the  solidarity  of 
coalitions  and  alliances,  as  it  did  during  Desert  Storm  in  1991,  and  provide 
a  response  to  crises  without  having  to  resort  to  offensive  measures. 

Finally,  BMD  can  strengthen  the  credibility  of  our  deterrent  forces  and 
provide  an  essential  hedge  against  the  failure  of  deterrence. 
[BMDOLINK] 

B.  DESCRIPTION  OF  BMD  SYSTEM 

The  Ballistic  Missile  Defense  Organization  (BMDO),  an  agency  of  the 
Department  of  Defense  (DoD),  is  “responsible  for  managing  directing,  and  executing  the 
BMD  Program.”  [BMDOLINK]  The  BMD  program  is  a  two-part  missile  defense 
program.  First  priority  is  given  to  Theater  Missile  Defense  (TMD)  to  meet  the  existing 
threat  to  deployed  U.S.  and  allied  forces.  Second  priority  is  assigned  to  National  Missile 
Defense  (NMD)  as  a  hedge  against  the  emergence  of  long-range  ballistic  missile  threats. 
[BMDOLINK] 

1.  Theater  Missile  Defense  (TMD) 

Theater  Mssile  Defenses  are  designed  to  protect  U.S.  deployed  troops  and 
coalition  forces.  TMD  systems  must  be  able  to  deploy  rapidly  and  be  highly  mobile. 
“Since  the  TMD  threat  is  diverse  with  respect  to  range  and  capability,  no  single  system 
can  perform  the  entire  TMD  mission.”  [BMDOLINK]  To  adequately  perform  TMD,  an 
integrated  Family  of  Systems  (FoS)  is  required.  (See  Table  1)  ‘The  FoS  concept  is  an 
evolving,  flexible  configuration  of  interoperable  weapon  systems.  Command  and  Control 
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(C2)  centers,  and  intemal/extemal  sensors.”  [BMD099G]  Development  of  these  systems 
is  dispersed  throughout  the  Services  and  Agencies.  BMDO  states  that  the  FoS  approach 
will  ensure  a  defense  in  depth,  utilizing  lower-tier  (low-altitude),  upper-tier  (high- 
altitude),  and  boost-phase  defenses.  [BMD099G] 


System  Name 

Deployment  mode 

Approximate  radius  of 
defended  area 

Intended  to  defend  against: 

Type  of  warhead 

|Lower-tier  theater  missile  defenses:  \ 

Patriot  PAC-2  (upgraded) 

Truck-mounted 

10-15  kilometers 

Short-range  missiles  with  range  up 
to  600  kilometers;  Aircraft 

Blast  fragment 

Patriot  PAC-3 

Truck-mounted 

40-50  kilometers 

Short-range  missiles  with  range  up 
to  1,500  kilometers;  Aircraft 

Hit-to-kill 

MEADS  (Medium-range 
Extended  Air  Defense  System) 

Truck-mounted 

Less  than  10  kilometers 

Short-range  missiles  with  range  up 
to  600  kilometers;  Aircraft 

Hit-to-kili 

Navy  Area  Defense 

Ship-based 

50-100  kilometers 

Short-range  missiles  with  range  up 
to  600  kilometers;  Aircraft 

Blast  fragment 

Upper-tier  theater  missile  defenses:  1 

THAAD  (Theater  High  Altitude 
Area  Defense) 

Ground-based; 
transportable  by  aircraft 

A  few  hundred  kilometers 

Short  and  medium-range  missiles 
with  range  up  to  3,500  kilometers 

Hit-to-kill 

Navy  Theater  Wide 

Ship-based 

More  than  a  few  hundred 
kilometers 

Short  and  medium-range  missiles 
with  range  up  to  3,500  kilometers 

Hit-to-kill 

Boost-phase  theater  missile  defenses:  ! 

Airborne  Laser 

Airplane 

Possibly  huge 

Short  and  medium-range  missiles 
with  range  up  to  3,500  kilometers 

Directed  energy 

Table  1.  US  Theater  Missile  Defenses 

This  table  lists  the  main  U.S.  theater  missile  defense  systems  that  are  either  operational  (Patriot  PAC-2)  or 
under  development.  [MOSH97] 


a )  Lower-Tier  Defenses 

Lower-tier  defenses  are  designed  to  intercept  missiles  low  in  the 
atmosphere  (at  altitudes  less  than  approximately  20  kilometers).  [MOSH97]  The 
interceptors  must  intercept  their  targets  in  the  atmosphere  because  the  interceptors 
maneuver  to  their  target  by  using  fins  to  steer  through  the  air.  Lower-tier  defenses  have 
relatively  slow-flying  interceptors  that  cannot  fly  very  far  before  intercepting  their  targets; 
therefore,  lower-tier  defenses  can  cover  only  relatively  small  areas.  Lower-tier  defenses 
are  designed  to  intercept  short-range  ballistic  missiles,  with  ranges  of  up  to  roughly  600 
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to  1,500  kilometers,  depending  on  the  system.  [MOSH97]  In  addition,  these  defenses  are 
designed  to  shoot  down  aircraft  and  cruise  missiles.  [BMD099G] 

The  United  States  currently  has  one  lower-tier  theater  defense  in  operation, 
the  Patriot  PAC-2.  The  lower  defense  systems  currently  under  development  by  the  U.S. 
are  the  Patriot  PAC-3,  the  Navy  Area  Defense,  and  the  Medium-range  Extended  Air 
Defense  System  (MEADS).  [BMD099A] 

(1)  Patriot  Advanced  Capability-2  (PAC-2).  According 
to  Mosher,  the  PAC-2  is  a  transportable,  truck-mounted  system  designed  to  defend  small 
areas  against  aircraft  and  ballistic  missiles  with  ranges  of  up  to  about  600  kilometers. 
[MOSH97]  The  interceptor  uses  a  "blast  fragmentation"  warhead  that  is  designed  to 
explode  once  it  gets  within  several  meters  of  its  target.  During  the  Gulf  War,  the  Patriot 
air  defense  system  made  its  “famous  battlefield  debut  against  tactical  ballistic  missiles 
and  helped  defend  coalition  forces  and  Israeli  territory  against  Iraqi  Scud  missile  attacks.” 
[BMD099D]  The  current  PAC-2  version  is  an  upgraded  version  of  the  Patriot  PAC-2 
defense  that  was  used  during  the  Gulf  War.  Since  the  Gulf  War,  BMDO  and  the  Army 
have  significantly  increased  the  effectiveness  of  the  Patriot  system  by  deploying  the  PAC- 
2  Guidance  Enhanced  Missile  (GEM)  which  was  developed  to  improve  the  Patriot’s 
accuracy  against  short-range  ballistic  missiles.  [BMD099D] 

(2)  Patriot  Advanced  Capability-3  (PAC-3).  Mosher 
describes  the  PAC-3  as  a  transportable,  truck-mounted  system  designed  to  defend  small 
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areas  against  ballistic  missiles  with  ranges  up  to  about  1,500  kilometers.  [MOSH97] 
Unlike  the  PAC-2,  this  system  does  not  use  an  explosive  warhead.  The  PAC-3  uses  a 
"hit-to-kill"  interceptor  (based  on  the  earlier  Erint  missile),  which  is  designed  to  destroy 
its  target  by  hitting  it  directly.  [MOSH97] 

According  to  BMDO,  the  PAC-3  is  a  core  TMD  system 
with  one  of  the  highest  priorities  in  the  development  of  BMD  systems.  [BMD099D]  Its 
mission  is  to  provide  the  lower  tier  of  the  BMD  architecture.  This  includes  defending 
troops  and  fixed  assets  from  short  and  medium-range  ballistic  missiles,  cruise  missiles, 
and  other  air  breathing  threats  such  as  fixed  or  rotary  wing  aircraft.  To  accomplish  this 
mission,  the  PAC-3  system  will  be  designed  to  be  a  “highly  advanced  missile  defense 
system  that  can  destroy  enemy  threats  with  hit-to-kill  accuracy  in  the  terminal  phase  of 
the  threat  missile’s  flight.”  [BMD099D]  “The  PAC-3  system  is  planned  to  be 
interoperable  with  other  Army  and  Joint  systems,  to  provide  a  seamless  missile  defense  in 
depth,  and  to  be  air-transportable  to  support  rapid  deployments.”  [BMD099D] 

PAC-3  systems  contain  four  basic  components:  a  radar  set, 
an  engagement  control  station  (ECS),  a  launching  station,  and  interceptors.  The  radar 
station  provides  warning  and  tracking  of  incoming  threats  and  a  continuous  update  link 
with  in-flight  interceptors.  ‘The  ECS  computes  fire  solutions  for  the  interceptor  and 
provides  fire  control  and  a  communications  link  with  other  Patriot  units.”  [BMD099D] 
The  launch  station  transports,  protects,  and  launches  the  missiles.  Each  launch  station 
can  be  equipped  with  four  GEM  or  earlier  missiles.  The  PAC-3  missile  uses  its  high 
maneuverability  and  hit-to-kill  accuracy  to  destroy  its  target.  [BMD099D] 
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(3)  Navy  Area  Defense.  Navy  Area  Defense  is  a  ship- 
based  system  designed  to  defend  small  areas  against  aircraft  and  ballistic  missiles  with 
ranges  up  to  600  kilometers.  [MOSH97]  Like  the  Patriot  PAC-2,  this  system  will  use  an 
explosive  warhead.  AEGIS  cruisers  and  destroyers,  equipped  with  a  modified  AEGIS 
combat  system  (ACS),  will  detect  and  track  short-to-medium  range  TBMs  and  engage 
them  with  the  Standard  Missile-2  (SM-2)  Block  IVA  interceptor.  [BMD099B] 

The  Navy  Area  Defense  system  “represents  a  lower-tier 
TMD  capability  that  can  take  advantage  of  the  strength  and  presence  of  the  naval  forces, 
and  build  upon  the  existing  AEGIS  infrastructure.”  [BMDOLINK]  Naval  vessels,  which 
are  routinely  deployed  worldwide,  are  currently  in  potential  threat  areas  or  can  be  rapidly 
redirected  or  repositioned.  A  Naval  TMD  capability  can  therefore  be  placed  within  a 
region  of  conflict  to  provide  TMD  protection  for  nearby  land-based  assets  before 
hostilities  erupt  or  before  land-based  defenses  can  be  transported  into  the  theater. 
[BMD099B] 

(4)  Medium-range  Extended  Air  Defense  System 
(MEADS).  The  last  of  the  lower-tier  systems  is  the  Medium-range  Extended  Air  Defense 
System,  formerly  the  Corps  SAM  [surface-to-air  missile]  program.  MEADS  is  the  only 
theater  missile  defense  system  under  consideration  to  provide  maneuver  forces  with  360- 
degree  defense  protection  against  the  real  and  growing  threat  of  short-range  tactical 
ballistic  missiles,  cruise  missiles  and  unmanned  aerial  vehicles.  [MOSH97]  This  system 
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is  intended  to  provide  fundamental  enhancements  in  tactical  mobility,  strategic 
deployability  and  operational  capability.  [BMD099F] 

MEADS  is  a  truck-mounted  system  designed  to  be  more 
mobile  than  the  Patriot  systems  and  to  be  deployed  with  ground  troops  as  they  move  in 
the  field.  [MOSH97]  By  contrast.  Patriot  is  designed  to  be  operated  from  a  single 
location  for  days  at  a  time  or  longer.  MEADS  uses  a  hit-to-kill  warhead  and  is  designed 
to  intercept  ballistic  missiles  with  ranges  of  up  to  600  kilometers.  MEADS  is  an 
international  program  under  joint  development  with  the  United  States,  Germany,  and 
Italy.  [BMD099F] 

b )  Upper-Tier  Defenses 

Upper-tier  defenses  are  designed  to  intercept  missiles  high  in  the 
atmosphere  or  above  the  atmosphere.  [MOSH97]  This  permits  large  ground  areas  to  be 
covered.  At  the  same  time,  upper-tier  defenses  are  designed  to  intercept  longer-range 
theater  missiles,  with  ranges  of  up  to  3,500  kilometers.  Upper-tier  defenses  are  also 
intended  to  be  used  as  the  first  layer  of  a  layered  defense  against  short-range  missiles, 
with  the  lower-tier  theater  defenses  providing  the  second  layer  of  defense.  [BMD099G] 

The  United  States  has  two  upper-tier  defenses  under  development.  Theater 
High-Altitude  Area  Defense  (THAAD)  and  Navy  Theater  Wide  (NTW).  Both  use  hit-to- 
kill  interceptors  that  maneuver  to  their  target  by  using  small  thrusters  to  change  their 
trajectory.  [MOSH97]  These  interceptors  operate  at  high  altitudes  where  there  is  not 
enough  air  to  enable  them  to  maneuver  by  using  fins.  The  interceptors  currently  under 
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development  use  infrared  sensors  to  detect  the  target  and  home  on  it.  These  sensors, 
which  detect  heat,  will  be  blinded  if  they  are  used  at  low  altitudes  where  the  air  resistance 
causes  heating  of  the  fast-flying  sensor.  Thus,  early  upper-tier  interceptors  will  have  a 
minimum  intercept  altitude  below  which  they  cannot  intercept  a  target.  [MOSH97] 

(1)  Theater  High  Altitude  Area  Defense  System 
(THAAD).  THAAD  is  a  land-based  system  intended  to  defend  large  areas  against 
missiles  with  ranges  of  up  to  3,500  kilometers.  [MOSH97]  THAAD  is  designed  to  be 
transportable  by  aircraft  and  to  intercept  missiles  high  in  the  atmosphere  (at  altitudes 
above  about  40  kilometers)  or  above  the  atmosphere.  The  THAAD  interceptor  has  a  top 
speed  of  about  2.5  kilometers  per  second.  [BMD099E] 

The  THAAD  system  is  a  critical  element  of  the  TMD  FoS. 
[BMD099E]  THAAD  is  used  to  engage  short,  medium,  and  long-range  ballistic 
missiles.  The  THAAD  system’s  ability  to  intercept  missiles  at  long  range  and  high 
altitude  (endo-  and  exo-atmospheric)  will  give  U.S.  forces  the  best  chance  to  shoot  down 
incoming  missiles  far  enough  out  so  that  post-intercept  debris  will  not  harm  U.S.  troops, 
which  is  a  vital  concern  if  a  missile  carries  a  weapon  of  mass  destruction.  [MOSH97] 
This  ability  will  also  give  the  U.S.  TBMD  forces  the  time  to  judge  the  success  of  an 
intercept  attempt  and,  if  necessary,  launch  more  interceptors  from  THAAD  or  other 
missile  defense  systems.  As  the  upper  tier  of  a  two-tiered  TMD  architecture,  THAAD 
provides  near  leak  proof  protection  when  employed  with  PAC-3  or  Navy  Area  Defense. 
[MOSH97]  THAAD  system  development  started  in  1992,  and  it  is  the  most  mature 
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upper-tier  system.  It  is  expected  to  be  fielded  in  2007.  Currently  THAAD  is  undergoing 
testing  and  development.  [BMD099E] 

The  THAAD  system  consists  of  four  principle  components: 
truck-mounted  launchers,  interceptors,  the  THAAD  Radar  system,  and  the  THAAD 
BM/C4I  system.  The  purpose  of  the  mobile  launcher  is  to  protect,  transport,  and  fire  the 
interceptors.  ‘The  interceptors  will  consist  of  a  single  stage  booster  and  a  kinetic  kill- 
vehicle  that  will  destroy  targets  by  colliding  with  them.”  [BMD099E]  The  THAAD 
radar  will  support  surveillance,  target  tracking,  and  fire  control  functions,  and  provide  a 
communications  link  with  THAAD  interceptors  in-flight.  THAAD’s  BM/C4I  system  will 
manage  and  integrate  all  THAAD  components.  [BMD099E]  The  BM/C4I  system  will 
link  the  THAAD  system  to  other  missile  defense  and  air  defense  systems  to  support  a 
multi-tiered,  highly  effective,  interoperable  TMD  architecture.  The  THAAD  system  will 
be  transported  by  air  on  a  C-141  cargo  aircraft.  [BMD099E] 

(2)  Navy  Theater  Wide  (NTW)  Defense.  NTW  is  a 
ship-based  system  intended  to  defend  large  areas  against  missiles  with  ranges  of  up  to 
3,500  kilometers.  [MOSH97]  NTW  is  designed  to  intercept  medium-  and  long-range 
TBMs  only  above  the  atmosphere;  it  will  use  the  LEAP  (lightweight  exo-atmospheric 
projectile)  kinetic  kill  vehicle,  which  cannot  intercept  at  altitudes  below  about  80-100 
kilometers.  [MOSH97]  The  system  will  not  be  able  to  intercept  short-range  missiles  with 
a  range  less  than  about  300-400  kilometers,  since  they  never  reach  an  altitude  of  80-100 
kilometers.  Navy  Theater  Wide  is  intended  to  intercept  targets  in  the  middle  of  their 
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trajectory  (in  mid-course)  or,  if  the  ship  can  position  itself  near  the  missile  launch  site,  in 
the  beginning  of  their  trajectory  shortly  after  the  missile  engine  finishes  burning  (in 
ascent/boost  phase).  The  interceptor  has  a  speed  of  about  4.5  kilometers  per  second. 
[BMD099C] 

The  system  will  be  deployed  on  AEGIS  ships,  which  use 
the  SPY  radar  system.  [BMD099C]  The  NTW  will  be  able  to  take  advantage  of  the 
mobility  of  Navy  AEGIS  equipped  ships  and  provide  BMD  protection  to  U.S.  and 
coalition  forces  throughout  the  world.  This  is  especially  important  in  the  early  stages  of 
conflict  when  land-based  BMD  assets  are  either  unavailable  or  limited  in  number  or 
location.  [BMD099C] 

A  second-generation  system,  Navy  Theater  Wide  Block  n, 
is  also  planned  for  deployment  after  2010.  This  system  will  use  a  faster  interceptor  and  a 
more  powerful  radar.  [BMD099C] 

c)  Boost-Phase  Defenses 

The  United  States  is  also  developing  systems  to  intercept  missiles  during 
the  early,  powered  part  of  flight  when  the  rocket  booster  is  burning.  This  part  of  the 
missile’s  trajectory  is  called  the  "boost  phase,"  and  the  ballistic  missile  defenses  are 
termed  boost-phase  defenses.  The  advantage  of  boost-phase  defenses  is  that  they  are 
designed  to  destroy  the  missile  before  the  warhead  and  any  decoys  are  released,  so  there 
would  be  only  one  target  to  destroy  rather  than  potentially  dozens  or  hundreds. 
[MOSH97]  A  boost-phase  defense  would  also  be  able  to  destroy  submunitions  before 
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they  were  released.  Deploying  chemical  or  biological  weapons  on  numerous 
submunitions  would  be  the  best  way  for  an  attacker  to  distribute  the  agents  and  would 
simply  overwhelm  any  mid-course  or  terminal  defense  system.  [MOSH97]  The 
disadvantage  of  boost-phase  defenses  is  that  the  boost  phase  lasts  for  only  a  few  minutes, 
and  the  interceptor  must  be  able  to  make  its  intercept  close  to  the  launch  site.  There  is 
currently  one  boost-phase  theater  defense  under  development,  the  Airborne  Laser  (ABL) 
[MOSH97] 


(1)  Airborne  Laser  (ABL).  ABL  is  designed  to  attack 
short  and  medium-range  missiles  during  their  boost  phase  with  a  laser  based  on  a 
modified  Boeing  747  airplane.  [MOSH97]  The  laser  would  be  targeted  on  the  missile, 
and  if  it  shined  on  the  same  spot  for  long  enough,  it  would  weaken  the  metal  surface  by 
heating  it  to  its  structural-failure  temperature,  where  the  strength  of  the  metal  falls 
dramatically.  For  theater  missiles,  the  airplane  must  be  within  several  hundred  kilometers 
of  the  missile  the  laser  is  attacking.  It  is  generally  assumed  that  the  airplane  would  need 
to  fly  outside  the  borders  of  a  country  to  avoid  being  shot  down  by  air  defenses;  thus,  this 
system  will  be  incapable  of  attacking  missiles  launched  from  the  interior  regions  of 
relatively  large  countries.  [MOSH97]  The  exception  would  be  in  a  conflict  in  which  the 
United  States  had  already  established  air  superiority.  In  principle,  the  airborne  laser 
would  also  be  capable  of  causing  a  long-range  missile  to  fail.  Russian  and  Chinese  land- 
based  missiles  are  not  assumed  to  be  vulnerable  to  the  ABL  though,  since  they  are  based 
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far  inland.  However,  the  airborne  laser  could,  in  principle,  threaten  Russia’s  long-range 
SLBMs.  [MOSH97] 

2.  National  Missile  Defense  (NMD) 

The  NMD  system  is  being  developed  to  protect  the  United  States  from  attack  by  a 
limited  number  of  ICBMs  armed  with  conventional,  nuclear,  biological,  or  chemical 
warheads.  [MOSH97]  Such  limited  attacks,  ranging  from  a  few  to  a  few  tens  of  missiles, 
fall  into  three  categories: 

1)  A  small  accidental  or  unauthorized  launch  from  Russia  (or  other  former  Soviet 
Union  country) 

2)  A  deliberate  or  unauthorized  attack  from  China,  which  has  some  two  dozen 
ICBMs  with  a  range  capable  of  reaching  the  United  States 

3)  A  deliberate  attack  from  a  hostile  emerging  missile  state  that  might  acquire 
long-range  ballistic  missiles  [MOSH97] 

The  third  threat,  focused  on  North  Korea,  Iran,  and  Iraq,  has  emerged  as  the 
primary  argument  for  a  near-term  NMD  deployment.  The  NMD  program  has  anticipated 
for  some  time  the  possibility  that  a  rogue  state  could  acquire  ICBMs  that  could  threaten 
the  United  States.  This  possibility  was  underscored  by  the  August  1998  North  Korean 
attempt  to  launch  a  satellite  on  a  Taepo  Dong-1  (TD-1)  missile.  [MOSH97]  The  launch 
demonstrated  some  important  aspects  of  ICBM  development,  most  notably  multiple- 
stage  separation.  While  the  intelligence  community  expected  a  TD-1  launch  for  some 
time,  it  did  not  anticipate  that  the  missile  would  have  a  third  stage  or  that  it  would  be  used 
to  attempt  to  place  a  satellite  in  orbit.  [MOSH97]  A  three-stage  variant  of  the  TD-1,  if 
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successfully  developed  and  deployed,  could  pose  a  threat  to  portions  of  the  United  States 
as  well  as  to  the  territory  of  U.S.  allies  and  friends.  [BMD099B] 

The  intelligence  community’s  current  view  is  that  North  Korea  is  more  likely  to 
develop  the  Taepo  Dong-2  (TD-2)  missile  as  a  weapon.  [BMDOOOA]  The  TD-2  is  a 
derivative  of  TD-1  technology,  employing  a  larger  first  stage  and  the  No  Dong  theater 
ballistic  missile  as  the  second  stage.  A  two-stage  TD-2  will  have  the  range  to  reach 
Alaska,  while  a  three-stage  variant  could  bring  most  of  the  lower  48  states  within  range  of 
North  Korean  ballistic  missiles.  The  intelligence  community  believes  North  Korea  could 
test  a  TD-2  at  any  time,  unless  it  is  further  delayed  for  political  reasons.  Other  rogue 
nations,  particularly  Iran,  could  test  an  indigenously  developed  ICBM  in  the  latter  half  of 
this  decade,  using  foreign  assistance.  These  nations  may  also  pursue  a  TD-type  ICBM, 
possibly  with  North  Korean  assistance  or  purchase  such  a  North  Korean  system  outright, 
in  the  next  few  years.  [MOSH97] 

The  NMD  system  being  developed  would  defend  all  fifty  states  against  a  small 
number  of  ICBMs  launched  by  a  rogue  state,  such  as  North  Korea.  [BMDOOOA]  The 
NMD  program  is  currently  in  its  development  phase.  A  decision  whether  to  begin 
deployment  of  a  limited  national  missile  defense  (NMD)  system  will  be  made  in  mid- 
2000  and  will  be  “based  on  technology  development,  affordability,  the  potential  threat, 
international  treaty  considerations,  and  competing  defense  priorities.”  [BMDOLINK] 

The  NMD  system  is  an  integrated  collection  of  subsystems,  referred  to  as 
"elements,"  that  perform  dedicated  functions  during  an  ICBM  engagement.  The  system 
will  include  Ground-Based  Interceptors  (GBI),  four  types  of  long-range  sensors  (the 


53 


Defense  Support  Program  satellites,  Space-Based  Infrared  System  satellites,  an  Upgraded 
Early  Warning  Radar  (UEWR),  and  a  Ground-Based  X-Band  Radar  (XBR)),  and  a 
BM/C4I  element.  [BMDOOOA] 

The  system  will  use  GBIs  topped  with  an  exo-atmospheric  kill  vehicle  (EKV)  that 
is  designed  to  destroy  the  incoming  warhead  by  colliding  with  it  at  high  speed. 
[BMDOOOA]  The  GBI  is  a  silo-based,  three-stage,  ICBM-class  missile  that  delivers  a 
separating  EKV  to  an  "acquisition  point"  above  the  atmosphere  en  route  to  engage  a 
threat  target.  [BMDOOOA]  At  this  point,  in  a  manner  similar  to  upper-tier  theater  missile 
defense  systems,  the  EKV  uses  an  infrared  seeker  to  acquire  and  track  the  target,  firing 
divert  thrusters  (for  terminal  guidance  and  control)  to  achieve  a  direct  hit  on  the  targeted 
reentry  vehicle.  This  collision  will  take  place  above  the  atmosphere,  when  the  warhead  is 
in  the  mid-course  of  its  trajectory.  [MOSH97] 

The  launch  of  an  attacking  missile  would  first  be  detected  by  U.S.  early  warning 
satellites.  The  existing  satellites,  known  as  Defense  Support  Program  (DSP)  satellites, 
use  infrared  sensors  to  detect  the  hot  plume  of  a  missile  booster  in  the  early  stage  of  its 
flight.  Beginning  in  2004,  the  DSP  satellites  will  be  replaced  by  a  new  system  of  early 
warning  satellites  known  as  SBIRS-high  (Space-Based  Infrared  System-high-earth  orbit), 
which  will  also  use  infrared  sensors  to  detect  missile  plumes  but  have  improved 
capabilities.  [BMDOOOA]  The  data  from  the  early  warning  satellites  will  be  fed  to  the 
NMD  Battle  Management  Center,  to  be  located  at  Cheyenne  Mountain  in  Colorado. 
[BMDOOOA] 
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Once  the  booster  finishes  burning,  the  NMD  system  will  use  different  sensors  to 
detect  the  missile  and  any  objects  it  releases,  to  track  these  objects  accurately  enough  to 
guide  the  interceptors,  and  to  discriminate  the  real  warhead  from  decoys  or  other  false 
targets.  [MOSH97]  These  sensors  include  five  existing  early-warning  radars,  in 
Massachusetts,  California,  central  Alaska,  Greenland,  and  Britain,  which  will  be 
upgraded  to  give  them  the  ability  to  track  targets  accurately  enough  to  guide  interceptors. 
[BMDOOOA]  New  XBRs  designed  specifically  for  NMD  and  with  much  greater 
discrimination  capabilities  will  also  be  deployed.  These  ground-based  radars  will  be 
supplemented  by  a  space-based  system  of  roughly  24  SBIRS-low  (Space-Based  Infrared 
System-low-earth  orbit)  missile-tracking  satellites  that  are  designed  to  provide  track  data 
accurate  enough  to  guide  interceptors  without  assistance  from  other  sensors. 
[BMDOOOA] 

At  some  point  in  this  process,  the  system  must  discriminate  the  actual  warhead 
from  the  other  objects.  Otherwise,  the  NMD  system,  having  a  limited  number  of 
interceptors,  would  risk  running  out  of  interceptors  if  it  attempted  to  fire  at  all  the  objects. 
[LEWI97]  Because  the  NMD  interceptors  are  designed  to  intercept  their  targets  above 
the  atmosphere,  where  there  is  no  air  resistance  and  where  lightweight  objects  travel  on 
the  same  trajectory  as  a  heavy  warhead,  the  system  will  be  particularly  vulnerable  to 
countermeasures  that  use  numerous  lightweight  decoys.  [LEWI97] 

The  NMD  Battle  Management  Center  will  integrate  the  information  from  the 
various  sensors  and  decide  which  objects  the  system  should  try  to  intercept.  The  NMD 
system  will  then  launch  interceptors  and  guide  them  towards  their  targets.  An  In-Flight 
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Interceptor  Communications  Systems  (IFICS),  which  will  consist  of  several  ground 
stations  deployed  at  forward  locations,  will  relay  communications  from  the  Battle 
Management  Center  to  interceptors  that  have  flown  over  the  horizon.  [MOSH97]  As 
each  interceptor  nears  its  assigned  target,  it  will  release  the  EKV,  which  will  use  infrared 
and  visible  light  sensors  to  detect  the  target  and  attempt  to  discriminate  it  from  decoys  or 
other  false  targets.  [MOSH97]  Finally,  the  EKV  will  home  on  the  target  and  use  thruster 
rockets  to  steer  itself  into  the  target. 

To  increase  its  odds  of  success,  the  NMD  system  would  likely  fire  several 
interceptors  at  each  target.  To  conserve  interceptors,  if  time  permits,  the  defense  will  use 
a  shoot-look-shoot  strategy,  in  which  one  or  more  interceptors  are  fired  at  the  target,  and 
after  observing  the  results  of  the  intercept  attempts,  additional  interceptors  are  fired  if 
necessary.  Current  plans  reportedly  call  for  firing  four  interceptors  at  each  target. 
[BMDOOOA] 

The  United  States  plans  to  build  the  NMD  in  three  stages,  with  the  capability  of 
the  system  designed  to  increase  in  each  stage.  [BMDOOOA]  The  first  system 
configuration,  called  the  Capability- 1  (C-l)  system,  is  designed  to  defend  against  an 
attack  of  a  "few,  simple"  warheads.  This  initial  system  would  be  augmented  to  provide  a 
Capability-2  (C-2)  system,  designed  to  defend  against  a  "few,  complex"  warheads.  The 
stated  goal  of  the  NMD  program  is  to  deploy  a  Capability-3  (C-3)  system,  designed  to 
defend  against  "many,  complex"  warheads.  The  term  "few"  refers  to  five  or  fewer 
warheads.  The  dividing  line  between  the  terms  "simple"  and  "complex"  refer  to  the 
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extent  to  which  the  attacker  has  incorporated  countermeasures  to  fool  or  overwhelm  the 
defense.  [BMDOOOA] 

These  three  system  configurations  will  differ  from  each  other  in  several  ways. 
The  most  obvious  difference  is  in  the  number  of  interceptors.  The  C-l  system  will  have 
20  interceptors  deployed  at  a  single  site  in  the  United  States,  the  C-2  system  will  increase 
the  number  of  interceptors  at  this  site  to  100,  and  the  C-3  system  will  deploy  a  total  of 
more  than  100  interceptors  at  multiple  sites  in  the  United  States.  [BMDOOOA]  The 
number  and  types  of  sensors  available  to  the  NMD  system  in  each  case  will  also  differ. 
The  number  of  X-band  radars  will  increase  as  the  system  evolved  from  the  C-l  to  the  C-3 
configuration,  and  the  SBIRS-low  sensors  would  first  be  deployed  with  the  C-2  system. 
[BMDOOOA] 

The  initial  site  will  be  either  Grand  Forks,  North  Dakota  or  central  Alaska.  The 
site  not  chosen  for  initial  deployment  will  likely  be  used  as  a  second  site  for  the  C-3 
system.  The  Clinton  administration  has  indicated  it  is  leaning  strongly  towards  an  initial 
deployment  in  Alaska,  as  depicted  in  Table  2.  [BMDOLINK] 
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C-l  Configuration 

C-2  Configuration 

C-3  Configuration 

Number  of  Interceptors 
Deployed  in  Alaska 

20 

100 

125 

0 

0 

125 

Upgraded  Early-Warning 
Radars 

Beale  (Marysville,  CA) 

Clear  (Alaska) 

Cape  Cod  (Mass.) 

Fylingdales  (England) 

Thule  (Greenland) 

Beale 

Clear 

Cape  Cod 

Fylingdales 

Thule 

Beale 

Clear 

Cape  Cod 

Fylingdales 

Thule 

South  Korea 

X-band  Radars 

Shemya  (Alaska) 

Shemya 

Clear  (Alaska) 

Fylingdales  (England) 

Thule  (Greenland) 

Shemya 

Clear 

Fylingdales 

Thule 

Beale 

Cape  Cod 

Grand  Forks  (ND) 

Hawaii 

South  Korea 

In-Flight  Interceptor 
Communications  Systems 

Central  Alaska 

Caribou  (Maine) 

Shemya  (Alaska) 

Central  Alaska 

Caribou 

Shemya 

Munising  (Michigan) 

Central  Alaska 

Caribou 

Shemya 

Munising 

Hawaii 

DSP  or  SBIRS-high? 

Yes 

Yes 

Yes 

SB  IRS-low? 

No 

Yes 

Yes 

Source:  US  Ballistic  Missile  Defense  Organization,  March  3,  1999  view  graph  j 

Table  2.  Preliminary  Architecture  for  C-l,  C-2,  and  C-3  NMD  Systems 


3.  Battle  Management/Command,  Control,  Communication,  Computers 
&  Intelligence  (BM/C4I)  System 

The  primary  goal  of  BM/C4I  is  “to  provide  the  warfighter  with  an  integrated 
BMD  capability  by  building-in  the  interoperability  and  flexibility  to  satisfy  a  wide  range 
of  threats  and  scenarios.”  [BMDOLINK]  BM/C4I  is  one  of  the  most  important  systems 
of  the  BMD  and  is  essential  in  order  to  take  advantage  of  the  full  capabilities  of  the  core 
BMD  weapons  systems.  “Successful  BM/C4I  increases  the  time  available  to  engage 
hostile  missiles,  increases  the  effective  allocation  of  interceptors,  and  reduces  the 
potential  for  attacking  missiles  to  penetrate  U.S.  defenses.”  [BMDOLINK] 
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According  to  BMDO,  “effective  BM/C4I  decreases  the  number  of  interceptors 
required  by  improving  weapon  system  fire  distribution  and  coordination  and  through 
sensor  fusion.”  [BMDOLINK]  It  provides  multiple  information  paths  between  sensors, 
shooters,  and  control  locations  to  combat  sensor  outages  and  jamming.  BM/C4I  weapon 
cueing  information  also  increases  battlespace  and  depth  of  fire,  improves  defense  against 
long-range  threats,  and  increases  the  defended  area.  BM/C4I  also  “supports  passive 
defense  measures  by  providing  greater  early  warning  and  faster  reaction  times.” 
[BMDOLINK] 

The  BM/C4I  architecture  for  TMD  is  built  upon  the  existing  C2  structure  for 
Theater  Air  Defense  (TAD)  and  adds  the  communications  linking  TMD  C2  nodes, 
weapons,  and  sensors,  and  the  TMD  interfaces  to  intelligence  systems  and  other 
supporting  capabilities.  [BMDOLINK]  Interoperability  in  BM/C4I  is  essential  for 
successful  joint  TMD  operations. 

C.  CHALLENGES 

All  ballistic  missile  defenses  are  vulnerable  to  countermeasures.  Despite  decades 
of  research,  dealing  with  countermeasures  remains  a  key  unsolved  problem  facing  missile 
defenses.  It  is  easier  for  the  attacker  to  deploy  effective  countermeasures  against  defenses 
than  it  is  for  the  defense  to  respond  to  such  countermeasures.  [LEWI97] 

Effective  countermeasures  can  be  cheap  and  use  simple  technology  -  much 
simpler  than  the  technology  required  to  build  long-range  missiles.  One  method  the 
attacker  can  use  is  to  overwhelm  the  defense  by  making  the  warhead  hard  to  detect. 
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leaving  the  defense  without  enough  time  to  intercept  it.  The  attacker  can  also  use 
methods  to  prevent  the  defense  from  identifying  the  true  warhead.  If  the  United  States 
deploys  a  national  missile  defense,  it  must  expect  that  any  developing  country  that  would 
build  or  buy  long-range  missiles  to  deliver  an  attack  would  also  make  sure  these  missiles 
had  countermeasures  to  penetrate  the  defense.  [LEWI97] 

Building  an  effective  defense  against  long-range  missiles  is  difficult  even  without 
the  use  of  countermeasures.  First,  the  ground-based  radar  or  satellite-based  sensor  must 
detect  and  track  the  attacking  warhead  early  enough  for  the  interceptor  to  reach  the 
warhead.  Second,  the  defense  must  accurately  calculate  the  projected  intercept  point  and 
launch  an  interceptor  toward  it.  Third,  the  infrared  sensor  on  the  interceptor  must  detect 
the  warhead  far  enough  away  to  give  the  interceptor  time  to  maneuver.  Finally,  the 
interceptor  must  maneuver  accurately  enough  to  hit  the  warhead,  which  is  a  small  object, 
at  a  closing  speed  of  greater  than  10  kilometers  per  second  (22,000  miles  per  hour). 
[LEWI97] 

The  attacker  does  not  need  to  do  much  to  make  intercepts  all  but  impossible.  To 
defeat  a  defense,  the  attacker  needs  for  only  one  countermeasure  to  work.  For  a  defense 
to  be  reliably  effective,  it  must  work  against  all  countermeasures  the  attacker  might  use 
and  must  work  the  first  time  it  encounters  them.  Many  countermeasure  techniques  are 
available  for  the  attacker  to  use.  Three  countermeasure  examples  are: 

1 )  The  attacker  can  overwhelm  the  defense. 

2)  The  attacker  can  make  the  warhead  hard  to  detect,  leaving  the  defense 
without  enough  time  to  intercept. 
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3)  The  attacker  can  prevent  the  defense  from  identifying  the  true  warhead. 

[LEWI97] 

1.  Attacker  Can  Overwhelm  the  Defense 

Chemical  and  biological  warheads  can  be  divided  into  many  small  parts  called 
submunitions  that  can  be  released  early  in  flight,  just  after  the  booster  stops  thrusting. 
This  creates  so  many  reentering  targets  that  it  overwhelms  the  defense  and  would 
therefore  defeat  any  midcourse  or  terminal  defense.  Dividing  the  warhead  into 
submunitions  is  also  beneficial  to  the  attacker  because  it  distributes  the  chemical  or 
biological  agent  more  efficiently  over  the  target  area.  The  intelligence  community  has 
stated  that  they  believe  North  Korea  will  be  able  to  deploy  submunitions,  and  that  this 
technology  could  be  available  on  the  world  market  by  2000.  [LEWI97] 

2.  Attacker  Can  Make  the  Warhead  Hard  to  Detect 

The  infrared  sensor  on  the  interceptor,  which  guides  it  to  the  final  intercept, 
detects  the  heat  emitted  by  the  warhead.  Cooling  the  surface  of  the  warhead  thus  makes  it 
more  difficult  to  detect.  A  small  amount  of  liquid  nitrogen  in  a  thin  shroud  surrounding 
the  warhead  could  cool  the  surface  enough  to  reduce  the  distance  at  which  the  infrared 
sensor  could  detect  the  warhead  by  10,000  times.  The  interceptor  would  have  only  a  few 
thousandths  of  a  second  to  react,  in  which  time  it  could  not  maneuver  enough  to  have  any 
chance  of  intercepting  a  warhead  traveling  at  7,000  meters  per  second.  [LEWI97] 

Such  cooling  would  also  make  the  warhead  much  less  visible  to  the  infrared 
detectors  on  satellite-based  sensors  such  as  the  planned  Space  and  Missile  Tracking 
System,  giving  the  defense  less  time  to  work.  Similarly,  the  warhead  can  be  made  more 
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difficult  to  detect  by  radar  by  reducing  its  radar  cross-section  using  simple  techniques 
such  as  adding  a  sharp  nose,  curving  its  back  end,  and  covering  it  with  radar-absorbing 
material.  [LEWI97] 

3.  Attacker  Can  Prevent  the  Defense  from  Identifying  the  True 
Warhead 

Above  the  atmosphere,  where  long-range  missiles  would  be  intercepted,  objects  of 
different  weights  and  shapes  travel  at  the  same  speed  and  follow  the  same  path.  This 
allows  a  missile  to  carry  a  large  number  of  lightweight  decoys  to  confuse  the  defense. 
These  decoys  do  not  need  to  be  aerodynamic  and  need  not  even  look  like  the  warhead 
since  the  warhead  could  also  be  disguised.  Such  decoys  would  force  the  defense  either  to 
launch  interceptors  at  all  the  targets  or  to  wait  until  the  atmosphere  strips  away  the 
lightweight  objects,  by  which  time  it  could  be  too  late  to  launch  interceptors  against  the 
warhead.  [LEWI97] 

A  simple  and  effective  countermeasure  is  to  place  the  warhead  in  a  metalized 
mylar  balloon  and  release  it  within  a  large  cloud  of  empty  balloons.  Each  of  these  targets 
would  move  at  the  same  speed  and  could  not  be  distinguished  by  the  missile  defense 
radar.  Adding  a  small  heater  to  each  balloon  to  heat  each  one  by  a  different  amount 
would  prevent  infrared  sensors  from  detecting  the  real  warhead.  If  desired,  the  attacker 
could  also  add  a  small  vibrator  to  the  balloons  to  mask  any  small  motions  the  warhead 
might  cause.  The  lightweight  balloons  would  be  stripped  away  by  the  atmosphere  late  in 
flight,  but  by  that  time  they  would  already  have  done  their  job.  [LEWI97] 


62 


4.  Summary 

Given  today’s  technology,  the  United  States  can  certainly  build  a  defense  that 
could  destroy  one  or  a  few  ICBM  warheads  under  controlled  conditions,  where  the 
characteristics  of  the  target  warhead  are  known  to  the  defense  and  no  serious  effort  is 
made  to  defeat  the  defense.  However,  the  real  question  is  whether  the  defense  will  be 
operationally  effective;  that  is,  will  the  defense  be  effective  in  the  real  world,  where  the 
characteristics  of  the  attack  would  not  be  completely  known  in  advance  and  where  the 
attacker  would  take  steps  to  defeat  the  defense?  The  key  issue  in  determining  operational 
effectiveness  will  be  how  well  the  system  can  deal  with  countermeasures  intended  to 
defeat  the  system.  [LEWI97] 

There  are  many  countermeasures  that  are  much  easier  to  build  and  deploy  than  is 
either  an  ICBM  or  a  nuclear  warhead  small  enough  to  be  delivered  on  an  ICBM.  Any 
country  that  has  developed  and  deployed  nuclear-armed  ICBMs  has  clearly  chosen  to 
devote  enormous  resources  to  acquiring  this  capability.  Thus,  the  United  States  must 
assume  that  any  country  with  the  technical  capability  and  motivation  to  deploy  an  ICBM 
to  attack  or  threaten  the  United  States  will  also  have  the  technical  capability  and 
motivation  to  deploy  countermeasures  to  the  U.S.  BMD  system.  [LEWI97] 
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V.  BALLISTIC  MISSILE  DEFENSE  SYSTEM  CASE  STUDY 


A.  VIEWPOINTS 

This  case  study  is  based  on  the  Ballistic  Missile  Defense  (BMD)  system.  We  will 
demonstrate  how  the  RM-ODP  viewpoints  can  be  used  to  aid  in  the  definition  of  policy, 
requirements,  and  specifications  of  the  BMD  system.  The  BMD  system  is  a  good 
candidate  to  model  using  viewpoints  because  it  is  a  complex,  distributed,  heterogeneous 
system  comprised  of  the  TMD  and  NMD  subsystems.  The  TMD  system  is  a  multi-tiered 
family  of  systems  further  divided  up  into  lower-tier,  upper-tier,  and  boost-phase 
subsystems.  There  are  currently  three  lower-tier  subsystems  being  developed  -  P AC-3, 
Navy  Area  Defense,  and  MEADS.  The  two  upper-tier  subsystems  being  developed  are 
THAAD  and  Navy  Theater  Wide.  The  only  boost-phase  subsystem  being  developed  is 
the  Airborne  Laser  system.  Figure  3  depicts  the  hierarchy  of  the  BMD  systems  under 
development. 
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Figure  3.  Hierarchy  of  BMD  System 


Ballistic  Missile  Defense  involves  many  challenges.  One  of  these  challenges  is 
the  ability  to  hit  a  moving  target.  The  use  of  countermeasures  by  an  attacker  makes  it 
more  difficult  to  hit  the  target.  Another  major  challenge  facing  BMD  is  interoperability 
amongst  all  the  systems.  The  RM-ODP  viewpoints  can  be  used  to  aid  in  modeling  the 
BMD  system  to  help  address  some  of  these  challenges. 

The  first  step  in  modeling  the  BMD  system  with  RM-ODP  is  to  develop  a 
reference  model.  The  reference  model  provides  the  “big  picture”  that  organizes  the 
pieces  of  an  ODP  system  into  a  coherent  whole.  A  reference  architecture  may  be  derived 
from  the  reference  model.  The  reference  architecture  is  a  starting  point  from  which 
detailed  specifications  can  be  built. 

To  construct  the  reference  model  of  the  BMD  system,  one  must  look  at  the  “big 
picture”  of  the  steps  required  to  hit  a  moving  target.  First,  DSP  satellites  using  infrared 


sensors  would  detect  an  attacking  missile.  This  data  is  fed  into  the  BM/C4I  network. 
The  next  step  is  to  calculate  the  projected  intercept  point  and  launch  an  interceptor  toward 
it.  After  the  boost  phase  of  the  attacking  missile,  sensors  in  early  warning  radars  are  used 
to  track  the  missile  and  discriminate  the  real  warhead  from  decoys.  The  early  warning 
radars  are  also  used  to  guide  the  interceptor.  The  infrared  sensor  on  the  interceptor  must 
detect  the  warhead  far  enough  away  to  give  the  interceptor  time  to  maneuver,  and  the 
interceptor  must  maneuver  accurately  enough  to  hit  the  warhead.  Figure  4  illustrates  the 
steps  required  to  hit  a  target. 


Figure  4.  Steps  Required  to  Hit  Moving  Target 


Once  the  reference  model  has  been  identified,  the  viewpoints  can  be  explored. 
RM-ODP  addresses  the  problems  faced  by  many  organizations  today,  especially  DoD,  in 
choosing  the  right  architecture.  This  case  study  uses  viewpoints  to  model  the  BMD 
system,  where  each  viewpoint  encapsulates  part  of  the  requirements  for  the  system.  The 
requirements  engineering  process  for  a  large,  complex  system  such  as  BMD  involves  the 
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participation  of  many  developers  with  different  specialties  and  roles  (such  as  contractor, 
project  manager,  electrical  engineering,  safety  engineering,  etc.).  Each  development  team 
can  hold  different  views  of  the  system.  Different  contractors  and  military  services  are 
additionally  building  each  of  the  subsystems  of  the  TMD  system.  Specifying  the  BMD 
system  using  the  RM-ODP  viewpoints  can  allow  for  an  otherwise  large  and  complex 
specification  to  be  separated  into  manageable  pieces  with  each  focused  on  the  issues 
relevant  to  each  member  of  the  development  team.  For  example,  the  systems  analyst 
works  with  the  information  specification  while  the  systems  programmer  is  concerned 
with  the  engineering  viewpoint.  The  following  sections  illustrate  how  the  five  different 
RM-ODP  viewpoints  may  aid  in  modeling  the  BMD  system. 

B.  ENTERPRISE  VIEWPOINT 

The  enterprise  viewpoint  focuses  on  the  purpose,  scope,  and  policies  for  the 
system.  There  are  many  policies  to  take  into  consideration  when  building  and  deploying 
such  a  wide  range  of  ballistic  missile  defense  systems.  The  success  or  failure  of  this 
system  will  depend  on  the  technology  used  in  the  defenses  and  the  tactics  and 
technologies  used  in  missile  attacks.  The  type  of  policy  that  is  modeled  in  this  case  study 
is  interoperability  of  all  the  BMD  subsystems.  Interoperability  is  an  ongoing  challenge 
for  the  U.S.  military.  With  the  military  becoming  more  joint,  interoperability  has  become 
an  even  more  important  issue. 

To  achieve  interoperability,  the  policy  of  interoperability  must  be  translated  into 
requirements  and  specifications.  A  BMD  system  is  a  real-time,  distributed  system,  so  the 
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issues  involved  are  complex.  This  distributed  operating  system  is  a  collection  of 
heterogeneous  systems  connected  via  a  network  that  presents  a  global  unified  view  of  the 
system  and  its  resources.  It  is  a  tightly  coupled  system  that  requires  all  participants  to  run 
their  own  copy  of  the  same  distributed  operating  system. 

In  the  enterprise  viewpoint,  policies  can  be  defined  in  terms  of  objects, 
communities,  and  the  roles  of  the  objects  within  the  communities.  Within  the  BMD 
community  are  objects,  which  are  either  passive  or  active.  Some  examples  of  active 
objects  may  be  the  contractors,  systems  engineers,  program  managers,  military  services, 
etc.  Examples  of  passive  objects  could  be  the  radar  systems,  the  interceptors,  BM/C4I 
network,  and  DSP  satellites. 

The  communities  are  groupings  of  objects  intended  to  achieve  some  purpose.  The 
BMD  system  can  be  expressed  in  terms  of  a  structure  of  communities.  The  BMD  system 
as  a  whole  is  the  community  which  is  comprised  of  two  main  subcommunities:  TMD  and 
NMD.  These  subcommunities  are  further  broken  down  into  more  subcommunities. 
Figure  5  is  an  illustration  of  the  TMD  subcommunity  portion  of  the  BMD  community, 
which  consists  of  three  additional  subcommunities. 


69 


Figure  5.  TMD  Subcommunity 


The  roles  of  the  objects,  whether  passive  or  active,  are  expressed  in  terms  of 
policies.  These  policies  dictate  the  behavior  of  the  objects  within  the  community.  These 
policies  have  varying  scope  and  may  apply  across  the  community,  to  a  role,  or  a  single 
action  type.  The  policies  can  be  implicit  or  explicit.  An  interoperability  policy  is  an 
explicit  policy.  Another  explicit  policy  in  the  BMD  system  is  a  security  policy. 

When  using  the  enterprise  viewpoint,  we  maintain  the  highest  level  of  abstraction. 
When  constructing  the  enterprise  viewpoint,  it  is  necessary  to  view  the  BMD  community 
as  a  combination  of  subcommunities  (see  Figures  3  and  4).  Each  of  the  objects  within  the 
subcommunities  (TMD  and  NMD)  has  specific  roles  that  they  must  perform.  The  objects 
within  the  three  subcommunities  of  the  TMD  subcommunity  also  have  specific  roles. 


Figure  6  is  a  simplified  example  of  the  enterprise  viewpoint  showing  the 
interoperability  policy  domain  of  the  BMD  system  or  community.  To  simplify  the  figure, 
only  the  TMD  and  NMD  subcommunities  are  modeled. 


Figure  6.  Enterprise  Viewpoint 


Figure  6  shows  three  interoperability  policy  domains:  1)  TMD  2)  NMD,  and  3) 
Joint  TMD  &  NMD.  Within  the  TMD  interoperability  policy  domain  are  interoperability 
requirements  between  and  within  each  of  the  subcommunities  of  TMD.  NMD  has 
interoperability  requirements  within  its  subcommunity  also.  The  Joint  TMD  and  NMD 
interoperability  policy  domain  define  interoperability  policies  between  the  TMD  and 
NMD  domains.  An  example  of  a  portion  of  the  joint  interoperability  policy  could  be  the 
following:  the  BMD  system  must  be  interoperable  amongst  all  of  the  TMD  and  NMD 
subcommunities.  A  robust  interoperable  C4I  system  (BM/C4I)  is  required  to  integrate  the 
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BMD  subcommunities  and  provide  commanders  with  the  facilities,  communications, 
automated  decision  aides,  and  information  they  need  to  effectively  plan  and  execute 
BMD  operations. 

C.  INFORMATION  VIEWPOINT 

The  information  viewpoint  focuses  on  the  semantics  of  information  and 

information  processing.  The  information  viewpoint  is  used  to  describe  the  information 
required  by  the  BMD  system  through  the  use  of  schemas,  which  describe  the  state  and 
structure  of  an  object.  This  viewpoint  can  be  used  to  further  decompose  the  BMD 
system. 

Figure  7  shows  an  example  configuration  of  RM-ODP  objects  in  an  information 
viewpoint  that  is  appropriate  to  the  policies  in  the  enterprise  viewpoint.  It  is  a  simplified 
example  of  the  information  viewpoint  showing  the  information  supporting  the  BMD 
community.  Once  again  only  the  TMD  and  NMD  subcommunities  are  modeled.  The 
principle  interoperability  feature  that  must  be  represented  is  the  fact  that  each  of  the  sets 
of  information  entities  is  isolated  from  the  others  and  that  information  only  needs  to  be 
interoperable  at  certain  levels  within  the  subcommunities. 
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Figure  7.  Information  Viewpoint 

Within  the  TMD  information  domain  are  interoperability  requirements  both 
between  and  within  each  of  the  subcommunities  of  TMD.  Each  subcommunity  within  the 
TMD  information  domain  contains  its  own  version  of  a  radar  system,  launch  system,  and 
interceptor,  and  thus  has  different  information  needs.  NMD  has  separate  information 
requirements  within  its  subcommunity  also.  The  Joint  TMD  and  NMD  information 
domain  would  define  information  that  is  shared  between  the  two  subcommunities,  and  the 
systems  that  share  this  information  need  to  be  interoperable. 

An  example  of  a  TMD  interoperability  policy  domain  could  include 
interoperability  between  the  TMD  and  NDM  subcommunities.  An  example  of  a  portion 
of  the  joint  interoperability  policy  is  the  C4I  system  required  to  support  the  BMD  system. 
A  robust  interoperable  C4I  system  (BM/C4I)  is  required  to  integrate  the  BMD 
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subcommunities  (TMD  and  NMD)  and  provide  commanders  the  facilities, 
communications,  automated  decision  aides,  and  information  they  need  to  effectively  plan 
and  execute  BMD  operations. 

D.  COMPUTATIONAL  VIEWPOINT 

The  computational  viewpoint  focuses  on  the  functional  decomposition  of  the 

system  into  objects,  which  interact  at  interfaces.  RM-ODP’s  computational  viewpoint  is 
object-based.  The  objects  encapsulate  data  and  methods,  offer  interfaces  for  interaction 
with  other  objects,  and  offer  multiple  interfaces.  The  computational  viewpoint 
decomposes  the  information  viewpoint  down  to  a  more  detailed  level. 

A  computational  specification  further  defines  the  objects  within  an  ODP  system, 
the  activities  within  those  objects,  and  the  interactions  that  occur  among  objects.  Most 
objects  in  a  computational  specification  describe  application  functionality,  and  these 
objects  are  linked  by  bindings  through  which  interfaces  occur.  The  binding  objects  are 
used  to  describe  complex  interactions  between  objects.  Figure  8  is  a  simplified 
illustration  of  the  BM/C4I  Network  object  with  a  lower-tier  interface  and  an  upper-tier 
interface.  Both  interfaces  can  be  used  to  destroy  a  target,  but  the  medium-range  targets 
can  only  be  destroyed  through  the  upper-tier  interface  and  the  short-range  targets  can  only 
be  destroyed  through  the  lower-tier  interface.  Each  of  the  BM/C4I  object’s  interfaces  is 
bound  to  a  TMD  object  (Navy  Area  Defense  or  NTW). 
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Figure  8.  Computational  Viewpoint 


E.  ENGINEERING  VIEWPOINT 

The  engineering  viewpoint  focuses  on  the  infrastructure  required  to  support 
distributed  interaction  between  objects  in  the  system.  The  engineering  viewpoint  is  not 
concerned  with  the  semantics  of  the  ODP  application,  except  to  determine  its 
requirements  for  distribution  and  distribution  transparency.  The  computational  viewpoint 
is  concerned  with  when  and  why  objects  interact,  while  the  engineering  viewpoint  is 
concerned  with  how  they  interact. 

When  modeling  interoperability  policy,  the  level  of  distribution  transparency 
needed  must  be  identified.  Of  the  eight  distribution  transparencies  mentioned  in  Chapter 
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2,  the  failure  transparency,  location  transparency,  access  transparency,  replication 
transparency,  relocation  transparency,  and  persistence  transparency  should  all  be 
considered.  Of  these  transparencies,  access  transparency  and  failure  transparency  are  the 
most  important  because  the  BMD  system  is  a  heterogeneous  real-time  system. 

Failure  transparency  masks  failure  within  the  distributed  system  to  enhance  fault 
tolerance.  If  a  link  or  system  within  the  distributed  system  fails,  the  entire  system  should 
not  fail. 

Access  transparency  is  also  an  important  transparency  for  the  developer  to 
consider.  Access  transparency  hides  the  differences  in  data  representation  and  procedure 
calling  mechanism  to  enable  interworking  between  heterogeneous  computer  systems. 
BMD  is  comprised  of  many  different  hardware  platforms,  operating  systems,  and 
programming  languages.  RM-ODP  does  not  try  to  standardize  the  components  of  the 
system  or  unnecessarily  influence  the  choice  of  technology. 

The  fundamental  entities  described  in  the  engineering  viewpoint  are  objects  and 
channels.  Objects  in  the  engineering  viewpoint  can  be  divided  into  two  categories  -  basic 
engineering  objects  and  infrastructure  objects.  Basic  engineering  objects  correspond  to 
the  objects  in  the  computational  viewpoint.  An  example  of  an  infrastructure  object  is  a 
protocol  object.  A  channel  corresponds  to  a  binding  or  binding  object  in  the 
computational  viewpoint.  A  channel  provides  the  communication  mechanism  and 
contains  or  controls  the  distribution  transparencies. 


76 


F.  TECHNOLOGY  VIEWPOINT 


The  technology  viewpoint  focuses  on  the  choice  of  technology  for  implementation 
of  the  system.  RM-ODP  has  very  few  rules  applicable  to  technology  specifications  and  is 
difficult  to  model.  This  viewpoint  further  decomposes  the  system  to  allow  for  the  choice 
of  the  distributed  computing  model  that  would  be  most  appropriate.  When  choosing 
which  distributed  computing  model  to  implement,  an  important  issue  to  consider  is  the 
time  constraint.  The  BMD  system  is  a  hard  real-time  system  that  must  satisfy  bounded 
time  constraints  or  suffer  severe  consequences.  The  consequences  of  an  undetected 
missile  are  severe;  if  a  missile  is  undetected,  it  could  inflict  death  and  destruction  in  the 
targeted  area. 

The  BMD  system  will  also  be  asynchronous  because  the  events  that  occur  are 
entirely  unpredictable  and  caused  by  external  sources.  One  cannot  predict  when  an 
adversary  may  launch  a  missile.  Load  consideration  should  also  be  considered  so  that  a 
single  radar  or  missile  system  is  not  overloaded. 

Another  important  issue  to  consider  when  choosing  the  technology 
implementation  of  the  BMD  system  is  the  network  characteristics.  There  are  four 
network  characteristics  that  can  affect  the  BMD  system:  1)  network  latency,  2)  bandwidth 
versus  cost,  3)  routing  optimization,  and  4)  micronetwork  characteristics.  Network 
latency  can  cause  problems  with  timing  predictability.  Distributed  real-time  applications 
require  constant  bandwidth  that  can  be  costly.  Distributed  real-time  systems  must  reside 
on  a  network  and  therefore  are  subject  to  the  network  topology  and  its  affect  on 
distribution  and  routing.  Distributed  real-time  systems  are  subject  to  micronetwork 
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characteristics,  such  as  buffer  size,  queue  sizes,  and  the  packet  sizes  allowed  on  the 
network. 

The  BM/C4I  system  is  one  of  the  most  important  systems  of  the  BMD  and  is 
essential  in  order  to  take  advantage  of  the  full  capabilities  of  the  core  BMD  weapons 
systems.  Successful  BM/C4I  increases  the  time  available  to  engage  hostile  missiles, 
increases  the  effective  allocation  of  interceptors,  and  reduces  the  potential  for  attacking 
missiles  to  penetrate  U.S.  defenses. 

G.  SUMMARY 

The  BMD  case  study  presented  only  a  simplistic  view  of  the  BMD  system.  The 
case  study  gave  examples  of  how  the  RM-ODP  viewpoints  can  be  used  to  model  BMD  at 
a  very  high  level.  The  five  RM-ODP  viewpoints  showed  aspects  of  the  distributed 
system  at  a  high  level  of  abstraction  chosen  by  the  developers  of  the  system.  Through  the 
use  of  RM-ODP,  the  various  members  of  the  development  team  can  combine  and 
coordinate  together  to  generate  specifications  for  the  system.  The  developers  can 
combine  and  coordinate  efforts  by  composing  the  various  views;  they  also  make 
transformations  between  levels.  When  transformations  are  made  between  different 
viewpoints,  though,  the  developers  need  to  ensure  that  the  views  are  consistent. 
Consistency  is  a  necessity  between  levels  as  well  as  across  viewpoints.  Another 
important  feature  of  RM-ODP  is  that  the  viewpoints  can  be  reused  at  the  various  levels  of 
abstraction. 
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VI.  CONCLUSIONS  AND  FUTURE  WORK 


A.  OBSERVATIONS 

In  this  thesis  we  defined  a  real  operational  problem  of  developing  the  complex 
distributed  system  known  as  BMD.  RM-ODP  and  viewpoints  were  defined,  and  the 
operational  problem  was  addressed  using  a  viewpoints  framework.  The  case  study 
showed  how  the  viewpoints  could  be  applied  at  a  very  abstract  level.  This  thesis 
demonstrated  that  the  RM-ODP  method  may  be  useful  for  DoD  in  developing  distributed 
systems. 

We  hypothesized  that  the  policy,  requirements,  and  specifications  could  be  dealt 
with  at  the  enterprise  level  in  a  very  abstract  manner.  The  original  hypothesis  that  the 
enterprise  level  would  be  the  level  to  address  interoperability  was  incorrect.  Multiple 
views  must  be  used  to  address  interoperability  policy  because  issues  of  interoperability  do 
not  tend  to  surface  until  you  get  down  to  the  lower  levels.  At  the  conclusion  of  the  case 
study,  it  was  realized  that  the  system  must  be  viewed  down  at  the  technology  and 
engineering  levels  to  make  any  firm  conclusions  regarding  interoperability. 

Interoperability  policy  can  still  be  implemented  at  the  enterprise  level  though 
because  it  can  be  made  explicit  in  the  policy  and  requirements  that  interoperability  is 
required  at  certain  levels  within  and  between  various  components.  Viewpoints  actually 
help  to  decompose  the  problem  into  manageable  pieces  at  each  level.  The  members  of 
the  development  team,  each  with  different  roles,  are  able  to  view  the  system  at  various 
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levels  of  abstraction.  A  systems  analyst  would  not  be  working  at  the  engineering  level 
but  at  a  higher  level  in  the  hierarchy  of  views.  The  engineering  level  is  concerned  with 
hardware  platforms  and  how  they  interoperate.  Viewpoints  support  the  division  of  labor 
and  the  idea  of  hierarchy  of  tasks. 

The  viewpoints  framework  can  aid  in  detecting  and  managing  any  inconsistencies 
that  may  arise  in  the  requirements  and  specifications  of  each  of  the  BMD  systems.  In  the 
BMD  system,  the  BM/C4I  system  will  link  the  subsystems  to  each  other  to  support  a 
multi-tiered,  highly  effective,  interoperable  BMD  architecture. 

Inconsistencies  provide  clues  about  missing  information.  A  reason  for  dealing 
with  inconsistencies  is  to  provide  a  more  robust  specification.  Viewpoints  can  be  used  as 
the  cornerstone  of  effective  inconsistency  management. 

The  main  goal  in  applying  RM-ODP  during  system  development  is  to  detect  as 
many  conflicts  as  possible  at  the  time  of  specification,  rather  than  leaving  them  to  be 
detected  at  runtime.  Conflicts  that  are  not  detected  until  runtime  can  endanger  the  lives 
of  the  military  and  many  civilians.  The  developers  can  modify  the  policies  to  remove 
conflicts  in  requirements  and  specifications. 

Viewpoints  will  help  determine  where  interoperability  is  necessary  and  sufficient, 
and  where  interoperability  should  be  optional  or  does  not  make  sense.  Interoperability  in 
some  systems  may  only  be  at  the  communications  level  where  you  are  passing  data  back 
and  forth  to  respond  to  a  threat  and  each  system  goes  about  addressing  that  threat 
however  it  is  best  suited  to  do  so.  Two  systems  could  work  in  a  coordinated  manner. 
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RM-ODP  can  be  used  to  help  us  address  these  issues.  It  brings  out  the  fact  that 
we  need  interoperability.  One  system  may  use  a  certain  type  of  radio  for 
communications.  At  the  technical  level  we  may  discover  that  we  have  two  different  types 
of  radios  that  are  not  compatible.  What  would  that  tell  you?  You  may  need  to  rethink 
your  system  and  go  back  up  to  a  higher  level  where  your  requirements  may  state  that  you 
must  use  interoperable  communications,  and  then  as  we  come  back  down  we  may  see  the 
discrepancies. 

B.  FUTURE  WORK 

It  is  important  to  realize  that  RM-ODP  is  a  framework  that  permits  us  to  focus  on 
different  viewpoints  of  a  system.  The  case  study  showed  how  the  viewpoints  could  be 
applied  at  a  very  abstract  level  and  how  RM-ODP  may  be  useful  for  DoD  in  developing 
distributed  systems.  Future  research  topics  could  include  the  detailed  application  of  the 
enterprise,  information,  computational,  engineering,  and  technology  viewpoints  to  other 
information  systems  being  developed.  Each  of  the  five  viewpoints  could  also  be 
individually  expanded  on  to  model  different  development  views  of  the  system.  The  area 
of  transformations  between  the  different  levels  of  viewpoints  and  consistency  could  be 
also  explored.  When  transformations  are  made  between  different  viewpoints,  the 
developers  need  to  ensure  that  the  views  are  consistent.  Consistency  is  a  necessity 
between  levels  as  well  as  across  viewpoints.  Another  area  of  research  could  be  the  idea 
of  viewpoint  reuse.  An  important  feature  of  RM-ODP  is  that  the  viewpoints  can  be 
reused  at  the  various  levels  of  abstraction. 
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APPENDIX  A:  ACRONYMS 


ABL 

BM/C4I 

BMD 

BMDO 

C-l 

C-2 

C-3 

C2 

C4I 

CORE 

DoD 

DSP 

ECS 

EKV 

FoS 

GBI 

GEM 

ICBM 

IEEE 

IFICS 

ISO 

ITU-T 

LEAP 

MEADS 

NMD 

NTW 

ODP 

PAC-2 

PAC-3 

RM-ODP 

SADT 

SAM 

SBIRS-high 

SBIRS-low 

SLBM 

SM-2 

SRD 

TAD 

TBM 

TBMD 

TD-1 

TD-2 

THAAD 

TMD 

UEWR 

VO  A 


Airborne  Laser 

Battle  Management,  Command,  Control,  Communications,  Computers,  and  Intelligence 

Ballistic  Missile  Defense 

Ballistic  Missile  Defense  Organization 

Capability- 1 

Capability-2 

Capability-3 

Command  and  Control 

Command,  Control,  Communications,  Computers,  and  Intelligence 

Controlled  Requirements  Expression 

Department  of  Defense 

Defense  Support  Program 

Engagement  Control  Station 

Exo-atmospheric  Kill  Vehicle 

Family  of  Systems 

Ground  Based  Interceptor 

Guidance  Enhanced  Missile 

Intercontinental  Ballistic  Missile 

Institute  of  Electrical  and  Electronics  Engineers 

In-Flight  Interceptor  Communications  Systems 

International  Standards  Organization 

International  Telecommunication  Union  -  Telecommunications  Standardization  Sector 

Lightweight  Exo- Atmospheric  Projectile 

Medium-range  Extended  Air  Defense  System 

National  Missile  Defense 

Navy  Theater  Wide 

Open  Distributed  Processing 

Patriot  Advanced  Capability-2 

Patriot  Advanced  Capability-3 

Reference  Model  of  Open  Distributed  Processing 

Structured  Analysis  and  Design  Technique 

Surface-to-Air  Missile 

Space-Based  Infrared  System-high-earth  orbit 

Space-Based  Infrared  System-low-earth  orbit 

Submarine  Launched  Ballistic  Missile 

STANDARD  Missile-2 

Structured  Requirements  Definition 

Theater  Air  Defense 

Theater  Ballistic  Missile 

Theater  Ballistic  Missile  Defense 

Taepo  Dong-1 

Taepo  Dong-2 

Theater  High  Altitude  Area  Defense 
Theater  Missile  Defense 
Upgraded  Early  Warning  Radar 
Viewpoint-Oriented  Analysis 
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VOSD 

VWPL 

XBR 


Viewpoints-Oriented  Software  Development 
Viewpoint  Language 
X-Band  Radar 
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